Информационная система (ИС) – программно-аппаратный комплекс, предназначенный для выполнения следующих функций, задач:

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

БД – центральное звено всей ИС.АБнД – автоматизированный банк данных.

Разделы курса основ БД:1) Характеристика современного состояния и этапы развития технологий БД. Понятие АБнД.2) Архитектура и пользователи АБнД. Этапы проектирования БД ИС.3) Инфологическое моделирование БД (I этап разработки БД). Модель “сущность-связь”.4) Моделирование локальных представлений ПО (предметная область). Объединение ЛП

(локальное представление).5) Методические аспекты разработки ИЛМ БД (инфологическая модель).Этапы погружения ИЛМ

в среду хранения данных СУБД. Выделяют три модели:a. Иерархическая модель данных (МД)b. Сетевая МДc. Реляционная МД

6) Понятие МД. Ограничения целостности БД.7) Сетевая МД.8) Иерархическая МД.9) Реляционная МД.10) Методические аспекты проектирования даталогической модели данных (ДМД).

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

11) Языки манипулирования данными. Язык SQL.12) Типовая организация СУБД. Понятие транзакций. Управление данными во внешней памяти.Распределенные БД.13) Технологии работы в архитектуре клиент-сервер и Web-технологии для БД.14) Инструментальные системы автоматизации проектирования баз данных (CASE система ERwin)

История развития БД.

1)МЛ

магнитная лента; 29 Мбит; последовательный доступ.

2)МБ

Магнитный барабан; прямой доступ.

3) (МД) Магнитные диски.Разные свойства хранения имели разные команды. Это определяло существенную зависимость

прикладной программы от данных. Изменение структуры данных определяло существенную модификацию прикладной программы. Это привело к появлению файловой системы – универсальной системы хранения данных.

С появлением ФС появляется универсальная система управления данными, которая позволяет работать с конкретным стандартным набором команд для управления данными, который действует для любых носителей. Работа производится на уровне файла → создать файл, открыть … и т.д.Минусы:

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

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

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

Этапы развития и современное состояние СУБД.

I этап. Имеет отношение к разработке СУБД для мейнфреймовых систем типа IBM 360/370 и ЕС1020-1060.

Эти мейнфреймовые системы использовались как многотерминальные системы с пакетной обработкой.

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

1964г. – первая IBM360В СССР было создано более 60 типов СУБДВ мире – 600 типов.В 1982, в ВоенМехе – ЕС ЭВМ 1020 №2.Пакетный режим – формировался пакет заданий, который потом последовательно обрабатывался,

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

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

Фирма IBM – IMS, DB2 → ОКА (советские)Culinet – СУБД IDMS → ДИСОДSoftware – ADABAS

– TOTAL → СеторИМЕС, БАНК, СУБД Польша

Хотя первые СУБД ориентированы на мейнфреймы, они обладали целым рядом недостатков, который можно оценивать с позиции сегодняшнего времени:

– отсутствие стандартов внешних интерфейсов – непереносимость программного продукта с одной платформы на другую.Появление такого класса систем сыграло весьма существенную роль в создании промышленных ИС

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

теоретические основы и положения по работе с данными:в 1975 – стандарт сетевой модели данных CODASYL. Этот стандарт определил многие положения

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

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

Пример: Система автоматизации воздушных перевозок.1ая система – СЕРЕНА была ориентирована на машины ЕС ЭВМ 1020, 1030 …СЕРЕНА 2 – 1050, 1060 – достаточно эффективно справлялась с автоматизацией.СЕРЕНА 3 – IBM 370 с использованием СУБД IMS (внедрена 5 лет назад и работает по сей день).Первые СУБД были ориентированы на:

1. Иерархическую модель данных.2. Сетевую модель данных.

Также создавались первые попытки создания систем реляционной модели данных: РМД→ DB2, dBVista. Следует отметить, что DB2 в настоящее время используется.

2

II этап. Появление РС привело к ориентации только на реляционную модель данных. Появляются

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

Ориентация на реляционную модель:1) Простота этой модели, в отличие от сетевой и иерархической.2) В реляционной модели используется высокая независимость данных от программ при

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

одной платформы на другую.На первых этапах развитие этого класса СУБД – они были ориентированы на персональные БД. Это

позволило в существенной мере упростить саму СУБД.Среди СУБД II типа можно выделить следующие ныне использующиеся:dBase, Clipper, FoxBase, FoxPro, Paradox, RiBase.Наработки в этих системах использовались позже в многопользовательских системах.Недостаток: большой объем работы по разработке.

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

приложение можно разбить на 3 компонента:1) компонент представления2) прикладной компонент3) компонент доступа к данным

В зависимости от того, как распределены эти компоненты по серверу и клиенту и выделяют 3-4 модели клиент-серверной архитектуры:

1) Модель файл-сервера2) Модель удаленного доступа к данным3) Модель сервера БД4) Модель сервера приложений.1) Модель файл-сервер предполагает, что в локальной сети, где связаны несколько вычислительных

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

Модель поддерживается своей ОС (СОС). На каждом клиенте размещается копия ядра СУБД. НА ФС хранятся только данные в виде файлов. Когда какой-то клиент запускает приложение, в котором имеются команды

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

Недостатки:1) Передается не требуемый кусок, а все или почти все.2) Защита возможна только на уровне файла.

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

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

3

ПК ПК ПК файл-сервер

СОС

Блокировка возможна на уровне файла или на уровне записей/полей записей.Транзакция – совокупность операций как единое целое – они либо выполняются полностью, либо не

выполняются совсем.2) Модель удаленного доступа к данным.

На сервере устанавливается централизованная БД, а обращения из клиентов осуществляются (на получение данных) на языке SQL. Возвращаются обработанные данные.

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

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

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

3)Модель сервера БД.Применительно к этой модели используется так называемый механизм процедур. Хранимые

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

После вызова процедуры осуществляется обращение к командам на языке SQL. Осуществляется обработка данных по заданному бизнес-правилу, и обработанные данные передаются клиенту.

Т.е. преимущества данной модели состоят:1) в уменьшении сетевого трафика.

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

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

сложно, то этим занимается администратор БД, а не клиенты.Централизованное администрирование приложений.ИС всегда открытые:

1) возможность ее модификации.2) дополнения и т.д.

Настройка приложений осуществляется централизованно – рассылка настроек с сервера на все клиенты.

4) Модель Сервер приложений.Характерным для сервера приложений является то, что прикладные функции выполняются на

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

Т.о. на сервере приложений выполняется отдельное приложение, которое обращается за данными на сервер БД на языке SQL.

Плюсы:1) мы разнесли приложения и

функции работы с данными на два отдельных сервера.4

кл1 кл2 кл3 клN

сервер БД

СУБД

БД

SQL-сервер

обработка данных

SQL

кл1 кл2 кл3 клN

сервер БД

СУБД

БД

SQLбиблиотека хранимых процедур

вызов хранимой процедуры

кл1 кл2 кл3 клN

сервер БД

СУБД

БДSQLсервер

приложений

SQLхранимая процедураданные

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

Есть четкое разделение бизнес-логикии доступа к данным. Основное приложение расположено на сервере приложений. Он работает под управлением своей многозадачной ОС и имеет среду для разработки разделяемых приложений и имеет среду для разработки т.н. промежуточного слоя (middle wave).

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

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

Основные характерные черты клиент-серверных систем.1) Эти системы позволяют (порождают) данные, а не информацию, т.е. в любом случае из всех трех

составляющих приложения, а именно:1. компонент представления.2. прикладной компонент.3. компонент доступа к данным

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

Пример: 1) данные 180, 23, 67 2) информация – если мы на данные наложим семантику, т.е. определим их структуру

180 – рост, 23 – возраст, 67 – вес.Т.е. перевод данных в информацию осуществляется в компоненте представления, который

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

Все клиент-серверные системы относятся к классу систем, поставляющих данные, а не информацию.2) Использование для обмена данными между клиентом и сервером протокола закрытого типа.Протокол закрытого типа является универсальным, но только для той среды, в которой была создана

эта модель.Каждая из СУБД поддерживает неполный набор SQL-операторов, а только какое-то подмножество,

причем вариант вызова различен для разных сред.3) Интерпретация и преобразование данных в информацию на клиенте.4) Размещение фрагмента ПО на клиенте. Распределенность приложения – часть приложения на

сервере, а часть на клиенте. Говорят о части приложения выполняемой на клиенте – “тонкий” / “толстый” клиент.

IV этап. Связан с появлением новых интернет и web-технологий и в частности, создание на их основе т.н.

интранет-систем для корпоративного использования.

Internet Interanet

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

Появление интернет-систем определило новый виток развития ИС, которое идет по спирали от мэйнфреймовых систем к системам Intranet, когда у нас имеет место такая же архитектура, но взаимодействие внутри сети осуществляется уже на других принципах.

5

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

Характеристические особенности Intranet -систем: 1) На сервере порождается конечный продукт в виде информации, в отличие от порождения

данных для клиент-серверной модели.2) Использование протокола скрытого типа, который определяет взаимодействие между

клиентской и серверной частью. Используется TCP/IP – протокол.3) Передача пользователю информации в удобном для нее виде.4) Размещение прикладного ПО только на сервере, на клиенте размещается только то средство,

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

1. Изначально на Web-сервере хранились HTML-страницы. Они были жестко запрограммированы (статичны), т.о. пользователь мог получить информацию и переходить по гиперссылкам для получения другой информации.

2. Введение возможности интерактивного обмена между юзером и web-сервером.

3. К Web-серверу подключается сервер БД и появляется возможность получения данных из БД SQL-сервера на основе запросов на языке SQL.

По URL-ссылке получаем вызов на Jave и получаем SQL-запрос…вызывается процедура, которая вызывает отображение HTML кода для пользователя. Т.о. получается трехзвенная схема.

Интерфейс обмена между Web-сервером и сервером БД – на языке SQL, интерфейс CGI, API.Все СУБД должны иметь средства для разработки приложений для среды.

Особенности современных СУБД, которые являются характерными для современно этапа развития.

1) Работа с распределенными БД.2) Использование методов ООП, как при создании БД, так и при разработке приложений.3) Использование технологии тиражирования данных, когда отдельные фрагменты БД

тиражируются непосредственно на клиентские места, а целостность БД поддерживается самой СУБД.

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

уменьшения обмена – наиболее часто используемые данные находились у клиента.

При тиражировании БД пользователем отправлялась копия фрагмента интегрированной БД.

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

Механизмы репликации (тиражирования) данных.1) по окончанию рабочего дня все фрагменты сравниваются с основной БД и вносятся

необходимые изменения.2) собирается набор изменений, и потом он пересылается на основной компьютер.

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

4) Многопотоковая архитектура построения. 5) Параллельная обработка запросов – одновременно выполняется несколько запросов пользователей.

6

ЭВП

Т Т Т

Ядро Interanet

ПК ПК ПК

БД

Web-сервер

ПК ПК ПК

сервер БД

HTML страница

SQL

ПК ПК ПК

ЛК1 ЛК2 ЛК3

БД

локальные БД

распределенная СУБД

ПК ПК ПК

ЛБД1 ЛБД2 ЛБД3

БД

локальные БД

Сервер

(ФБД)

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

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

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

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

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

a. Обычное резервное копирование – либо вся БД, либо наиболее ответственные (уязвимые) фрагменты БД копируются.

b. Использование системного журнала, в который заносятся все те изменения, которые имели место при работе с данными. Т.е. конкретная запись, конкретная операция, которая выполнялась над этой записью, конкретные начальные и конечные состояния полей записей – все это хранится в журнале и имеется возможность последовательного восстановления данных. С целью обеспечения минимального времени восстановления БД в случае крушения целесообразно использовать совместно эти два механизма. В случае сбоя и существенных разрушения БД:

1) сначала обеспечивается откат БД на конкретный момент времени, который соответствует резервной копии.

2) Применительно к восстановленной резервной копии осуществляется модификация в соответствии с теми командами, которые записаны в системном журнале.

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

5. Наличие развитого механизма тиражирования данных с целью приближения этих данных непосредственно к пользователю.

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

7. Обеспечение режимов безопасного доступа к данным путем использования механизмов установки различных привилегий, имеющих отношение к загрузке и обработке данных. Более широкое использование средств по безопасности БД (низкий уровень ФС).

8. Включение в состав программного обеспечения средств, которые позволяют работать с сервером в составе сетей Интернет и интранет. Это средства, которые обеспечивают средства включения СУБД в состав сетей.

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

В настоящее время существует много совокупностей СУБД и серверов, которые обеспечивают данные особенности и требования.

Пример:1) СУБД Oracle → Oracle 9.0 (10.0)

Кроме самого сервера БД, еще есть т.н. многочисленное окружение, которое позволяет проектировать в автономном режиме БД.

2) СУБД Sybase3) СУБД Ingress → фирма Ingress Corporation → Computer Asocial4) СУБД Informix

Все эти фирмы имели отношение к начальной стадии разработки СУБД.5) Interbase SQL Server → Borland6) Microsoft SQL Server (версия 6.0 → версия 2005)

7

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

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

входят следующие обеспечения:1. информационное2. программное (системное и специальное)3. техническое4. лингвистическое5. организационно

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

В англоязычной литературе используется термин “Система БД” (database system), который по своему содержанию близок введенному понятию АБнД. Согласно семантике русского языка, понятие “системы БД” воспринимается уже, чем оно обозначает в действительности.Отличительные особенности БнД:

1. БнД создается не для решения одной задачи, а для коллективного многоцелевого использования.

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

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

Преимущества БнД:1. Реализация принципа однократного ввода и многоаспектного использования данных. Единое

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

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

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

8

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

5. Устранение противоречивости хранимых данных. Следствием устранения избыточности данных является устранение возможности возникновения противоречивости одних и тех же данных в различных приложениях.

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

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

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

Предпосылки широкого использования БнД:1) Информационные потребности различных пользователей существенно пересекаются,

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

2) Функции создания, ведения БД и предоставления нужных данных являются универсальными. Создание специализированного ПО для выполнения этих функций приводит к повышению уровня выполнения этих функций и сокращению трудоемкости создания ИС.

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

Компоненты БнД:

1.Информационный компонент. Ядром БнД является БД – поименованная совокупность взаимосвязанных данных, находящихся под

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

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

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

данными);- о возможных значениях и форматах представления данных;- об источниках возникновения данных;- о кодах защиты и разграничения доступа к данных.

9

Преимущества использования словаря данных – централизованное накопление и описание суммарного ресурса данных системы на этапах проектирования и функционирования БД.

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

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

Описание ПО позволяет получать не только в автоматизированном режиме БД применительно к конкретной СУБД, но и целого ряда других СУБД, делая тем самым продукт универсальным. Тем не менее основная заточенность продукта ориентирована на ту среду, для которой он предназначен.

2. Программные средства БнД.Программные средства БнД обеспечивают взаимодействие всех частей системы при её

функционировании.

СУБД – основа прогр. средств БнД:1. Ядро СУБД – обеспечивает организацию ввода, обработки и хранения данных.2. Утилиты : компоненты настройки системы, средства тестирования, утилиты выполнения

вспомогательных функций (восстановление БД, сбор статистики, защита БД и др.).3. Трансляторы или компиляторы для используемых языковых средств.4. ПП обслуживания БнД – для обработки запросов к БД.

Все ПО работает в среде ОС (обеспечивающей взаимодействие компонентов ПО БнД).Языковые средства СУБД – важнейший компонент БнД, т.к. обеспечивает интерфейс пользователей

различных категорий с БнД. Языковые средства современных СУБД относится к языкам четвертого поколения (1ое – машинные языки, 2ое – символические языки ассемблера, 3ое – алгоритмические языки типа PL, COBOL, Pascal и др.)

3. Языковые средства.Языки 4-го поколения. Основная концепция языков 4го поколения: люди стоят дороже, чем машины.

При их проектировании используются следующие принципы:1) Принцип min работы (язык должен обеспечивать min усилий, чтобы заставить машину работать)2) Принцип min мастерства (работа должна быть так проста, как это возможно)3) Принцип естественности языка (язык не должен требовать значительных усилий в изучении

синтаксиса и мнемоники) 4) Принцип min времени доступа к данным (язык должен позволять без существенной задержки

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

“вылавливать” их)6) Принцип min поддержки (механизм языка должен позволять вносить изменения в приложения)7) Принцип max результат (языки n-го поколения должны представлять пользователю мощный

инструмент для решения разнообразных задач)Компоненты языка 4-го поколения для построения приложений

10

Спектр языковых средств, применяемых в СУБД, достаточно широк.Различают: ЯОД (язык описания данных), ЯМД, язык запросов, языковые средства разработки

приложений и другие языковые средства.В составе ЯОД в зависимости от СУБД поддерживаются: ЯО схем, ЯО подсхем, ЯО хранимых

данных, ЯО внешних данных.ЯМД разделяются на процедурные и непроцедурные. При использовании процедурных языков надо

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

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

Примером непроцедурных языков являются языки основанные на реляционном исчислении (SQL).Языковые средства предназначаются для пользователей различных категорий: конечных

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

По своим функциональным возможностям выделяются следующие категории языков:1. Генераторы приложений (обеспечивают возможность описания непроцедурным путем

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

виде требуемых документальных форм).3. Графические языки (позволяют выводить данные в виде различных графиков и диаграмм).4. Языки запросов-обновлений (позволяют формировать сложные запросы, относящиеся к

нескольким взаимосвязанным записям, а также обновлять записи)По форме представления различают аналитические, табличные и графические языковые средства

(относится к ЯОД и ЯМД).Для одних и тех же целей могут использоваться языки разных типов. Например, в СУБД FoxPro для

манипулирования данными используются:а) язык программирования FoxPro (процедурный язык с позаписной обработкой);б) табличный язык запросов QBE;в) непроцедурный язык SQL.Большинство современных СУБД включает в свой состав несколько языковых средств разного

уровня. В дополнение к ЯОД, ЯМД FoxPro включает генераторы экземп. форм, отчетов, приложений, меню и др.

4. Технические средства БнД. До появления ПК БнД реализовывались на мэйнфреймовых системах (больших ЭВМ, язык MSGraf).

В настоящее время на ПК.

5. Организационно-методические средства. Представляют собой различные инструкции, методические и регламентирующие материалы,

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

11

БнД (разработчики структуры БнД; прикладные программисты, системные программисты, специалисты по техническим средствам, специалисты по вводу данных)

Основные функции администратора БнД:1) Анализ предметной области (описание ПО, выявление ограничений целостности, определение

статуса информации, определение потребности и статуса пользователей, определение объемно-временных характеристик обработки данных).

2) Проектирование структуры данных (определение состава и структуры БД, связей между файлами БД, выбор методов доступа, описание структуры БД на ЯОД)

3) Задание ограничений целостности при описании структуры БД и процедур обработки БД.4) Первоначальная загрузка и ведение БД.5) Защита данных (пароль на вход в систему, определение прав доступа к данным, фиксация

попыток несанкционированного доступа, исследование случаев нарушения защиты и т.д.)6) Обеспечение восстановления БД (организация ведения системных журналов)7) Анализ эффективности функционирования БнД (время обработки, объем памяти, стоимостные

показатели, реорганизация и реструктуризация БД)8) Работа с пользователями (сбор информации об изменениях ПО, об оценке пользователями

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

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

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

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

FoxPro for Windows.СУБД FoxPro 1.0 была выпущена в 1989г. на смену СУБД FoxBase. Были выпущены несколько

версий СУБД: 1.0, 2.0, 2.2, 2.5 – для DOS 2.5, 2.6, 3.0, 5.0, 6.0, 7.0, 8.0, 9.0 – для Windows.

Версии 3.0, 5.0, 6.0, 7.0, и 8.0 – объектно и событийно ориентированные визуальные системы. Пользовательский интерфейс FoxPro всегда был гибким и дружественным, а быстродействие ставили его вне всякой конкуренции. В настоящее время большое число СУБД, однако ни одна не может сравниться со скоростью FoxPro при обслуживании БД. Производительность FoxPro по быстроте поиска и выборке записей из БД, содержащих тысячи и даже миллионы записей, еще не достигнута.

С появлением VFP производительность не ухудшилась. Зато стало легче получить доступ к файлам ODBC-совместимых БД (ODBC –Open Database Connectivity, является стандартным протоколом для серверов БД). Можно напрямую работать с данными Access Paradox, dBase и др. Настоящей революцией можно назвать появление поддержки структур клиент-сервер.

СУБД FoxPro относится к классу настольных (desktop) СУБД ПК, таких как: dBase (II, III, IV, V), Clipper, RiBase, Paradox и др.

В таких СУБД записи и поля имеют обычно фиксированную длину (длина записи – 4÷65 Кбайт). Исключение составляют поля типа Memo и General (переменная длина). Число полей варьируется от 128 до 1024. Длина поля зависит от типа поля и может составлять от 255 до 4000 байт для текстовых полей, до 20 байт – для числовых, имеет фиксированные значения для полей типа даты - 8 байт и логических полей – 1 байт.

Поле типа Memo служит для хранения больших массивов текстовой информации и хранится в отдельном файле БД, но воспринимается как поле в составе основного файла БД. Это поле имеет плавающую длину, определенную объёмом введенной текстовой информации и может достигать 32 Кбайт. Поле типа General предназначено для хранения изображения и других двоичных данных.

Большинство СУБД позволяют создавать файлы с числом записей до 1 млрд. и объемом десятки Гигабайт.

12

Функциональный состав СУБД.

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

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

(создание структуры файлов БД, манипулирование данными, создание ПП, экранных форм ввода-вывода и т.д.).

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

Команды языка СУБД записываются в специальный программный файл. Для его выполнения необходимо преобразование в вид исполнимых машинных команд.

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

Интерпретатор: программа занимает немного места в памяти, возможна покомандная отладка, недостаток – медленно.

Компилятор: быстрое выполнение, но много места, в т.ч. и исполняемые библиотеки.Стремление повысить скорость выполнения команд в режиме интерпретации привело к

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

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

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

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

Особенностью VFP является использование ООП, с настоящими классами и всеми их возможностями наследования, инкапсуляции и полиморфизма.

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

используя при этом все остальные возможности VFP.

13

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

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

• пользователи, которым необходимо использование многих функциональных возможностей СУБД, в том числе и команды языка, но не требуется создание сложных программ;

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

– командный режим, III группа – полный набор (создание exe модулей, отчуждаемых БД, оторванные представления и др.).

Этапы проектирования БД.В БД отражается информация об определенной предметной области (ПО). ПО – часть реального

мира, представляющая интерес для данного использования. В автоматических информационных системах отражение ПО представлено моделями данных (МД) нескольких уровней. Понятие “данные” в концепции БД – это набор конкретных значений, характеризующих объект. Данные не обладают определенной структурой, данные становятся информацией, когда пользователь задает им определенную структуру, т.е. определяет их смысловое содержание. Поэтому центральным понятием в области БД является понятие модели. Модель данных – это некоторая абстракция, которая при приложении к конкретным данным позволяет трактовать их уже как информацию, т.е. сведения, содержащие не только данные с их характеристикой, но и взаимосвязь между ними. Число уровней моделей зависит от особенности СУБД, от числа уровней её архитектуры.

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

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

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

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

Физическая МД используется для привязки ДЛМ к среде хранения. Эта модель определяет используемые ЗУ, способы физической организации данных в среде хранения, методы доступа, определение размера физического блока, определение целесообразности сжатия данных, проблемы буферизации (определение числа и размеров буферов, используемых при передаче данных из внешней памяти во внутреннюю).

В настоящее время наблюдается тенденция к сокращению работ на стадии физического проектирования и скрытия их от проектировщиков.

14

Внешняя МД используется в некоторых СУБД для описания логической стороны БД с точки зрения конкретного пользователя (описание - подсхема). Использование подсхем облегчает работу пользователя, т.к. он должен знать структуру не всей БД, а только той её части, которая имеет непосредственное отношение к нему.

Для проектирования структуры БД необходима исходная информация о ПО. Эта информация не зависит от особенностей СУБД. В тех случаях когда СУБД в явном виде не поддерживает подсхемы, эти функции могут выполнять другие компоненты системы. Близким к понятие подсхемы является понятие “взгляд” (view).

Инфологическая модель ПО – формализованное описание ПО, выполняемое без ориентации на используемые в дальнейшем программные и технические средства. Обычно в процессе инфологического проектирования используется модель “объекты-связи”. Она определяется в терминах: атрибут, объект, структурная связь.

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

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

СОТРУДНИК – объект.ФИО, ДОЛЖНОСТЬ, ОКЛАД, СТАЖ, ТЕЛЕФОН – атрибуты.Различают тип объекта – набор однородных объектов, и экземпляр объекта – реализация типа

объекта в конкретных значениях атрибутов.Структурная связь – иерархическое отношение между объектами двух типов: владельцем и

подчиненным.

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

проектирования является описание логической структуры БД на ЯОД. Для большей наглядности сначала строится схематическое графическое отображение структуры БД.

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

По своей структуре записи могут быть с постоянным и переменным составом (отсутствие или наличие полей: ВУЗ, степень, уч. звание и др.).

Запись характеризуется также типом и длиной. Различают записи с фиксированной (постоянной), переменной и неопределенной длиной (имя с переменной длиной и числом полей).

Основными характеристиками поля является его тип и длина.

Межзаписная структура.Традиционное деление СУБД по типу модели данных на реляционные, иерархический и сетевые

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

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

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

15

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

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

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

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

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

Если какая-то таблица содержит внешний ключ, то она:1. логически связана с таблицей, содержащей соответствующий первичный ключ;2. эта связь имеет характер “один-ко-многим” (таблица, содержащая внешний ключ, находится на

стороне “много” в этой связи).Связь “ключ”- “внешний ключ” в РМ определяют наличие связи 1:М между записями

соответствующих файлов.В VFP: Regular, Unique, Candidate, Primary.В реляционных СУБД часто используются понятие “взгляд” (view). Он представляет собой

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

Таблица “Служащие”первичный ключ ↓Номер сл. Имя Пол Звание Дата рожд. Код профессии Должность З/пл55730 1 03 73 Бухгалтер55720 0 05 45 Консультан

т ↑ идентификатор объекта внешние ключи

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

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

Таблица “Профессия”Код профессии Профессия Тарифная сетка Нормативы сдачи ЭПЗ на разряд

Отношение М:1 “Служащие” – “Профессия”

первичный ключ Таблица “Наряд” внешний ключ

Код наряда Дата Стоимость работы Характеристики Номер служащего

Отношение 1:N “Служащие” – “Наряд”При работе со связанными таблицами возможны нарушения целостности БД (разрушение данных и

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

16

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

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

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

1) Тип и формат поля автоматически допускает ввод только данных определенного типа (поле Data)((812)259-10-20)

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

3) Недопустимость пустого поля позволяет избежать появления в БД “ничейных” записей, в которых пропущены какие-либо обязательные атрибуты (NOT NULL).

4) Задание списка значений, позволяет избежать ошибок при вводе значений полей, особенно ключевых значений.

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

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

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

требует анализа более одного поля записи. Например, при вводе данных о новом сотруднике, можно проверять превышает ли его возраст 18 лет (анализ ДР и дня приема).

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

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

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

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

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

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

- удаление записей в родительской таблице без удаления подчиненных дочерних записей.В FoxPro (начиная с 3.0) условие целостности данных определяется на уровне описания БД, и в

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

Окно диалога конструктора условий целостности данных (Referential Integrity Builder ) обеспечивает задание следующей последовательности действий:

1. При изменении значения первичного ключа или ключа связи в родительской таблице:а) каскадное изменение всех соответствующих значений в дочерней таблице.б) не позволяет изменять значения полей первичного ключа или ключа связи в родительской

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

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

записи в дочерней таблице.

17

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

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

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

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

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

Для таблиц можно определить следующие триггеры:Insert – определяет действия, которые будут выполняться после добавления или вставки новой

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

выполняется. В противном случае выполнение не происходит и формируется сообщение об ошибке.

Индексы.Одним из основных требований, предъявляемых к СУБД, является возможность быстрого поиска

требуемых записей среди большого объема данных. В РСУБД обычно используются два основных способа поиска данных: последовательный поиск записей и поиск по индексу. При последовательном поиске данных осуществляется перебор всех записей файла БД.

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

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

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

порядковый номер записи в основной области Поэтому при поиске записи осуществляется не последовательный просмотр всей таблицы, а прямой

доступ к записи на основании упорядоченных значений индекса.а) последовательное сканированиеб) блочный поискв) двоичный поискПоследовательный поиск.Последовательный поиск заключается в последовательной проверке всех записей индексного файла

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

Бинарный или двоичный поиск.Записи в индексном файле упорядочены по возрастанию или убыванию значения первичного ключа.Кзп1<Кзп2<…<КзпnМетод бинарного поиска основан на делении интервала поиска пополамАлгоритм поиска.Индексный файл считают упорядоченным по возрастанию ключа. Сравнивают значение ключа

средней записи Ki, где i=┌Nзап файл/2┐ с заданным значением Кзад. Если Ki = Кзад, то поиск удачный ↑ округление до ближайшего большого целого

и алгоритм заканчивает свою работу. Если Ki < Кзад, то для продолжения поиска выбирается средняя запись правой половины файла: Зi …, Зj …. ЗN, где i=┌Nзап файл/2┐, j = i + ┌(Nзап файл-i)/2┐.

18

Если Ki > Кзад, то для продолжения поиска выбирается средняя запись левой половины файла:З1, З2, … Зj, …,Зi,…,ЗN, где i=┌Nзап файл/2┐, j =┌(Nзап файл-i)/2┐.Процесс деления интервала пополам продолжается до тех пор, пока не будет найдена искомая запись

(Ki = Кзад), либо пока в интервале не останется всего одна запись.Блочный поиск. Бинарный поиск можно выполнять работая с большим индексным файлом, а не с

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

Применительно к FoxPro различают два типа индексных файлов:1. Простые индексные файлы.Простые индексные файлы имеют расширение имени файлы IDX и содержат по одному элементу

для каждой записи данных таблицы БД.2. Мультииндексные файлы.Мультииндексные файлы имеют расширение CDX и могут осуществлять управление одновременно

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

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

Инфологическое моделирование.Общие сведения об инфологическом моделировании.ИЛМ предметной области строится первой. Предварительная ИЛМ строится еще на предпроектной

стадии и затем уточняется на более поздних стадиях проектирования. Затем на ее основе строится ДЛМ. После этого строится физическая и внешняя модели. Процесс проектирования БД может быть представлен в следующем виде:

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

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

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

19

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

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

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

Требования, предъявляемые к ИЛМ.1. Основное – адекватное отображение ПО, поэтому язык для представления ИЛМ должен

обладать достаточными возможностями для отображения явлений, имеющих место в ПО.2. ИЛМ должна быть непротиворечивой.3. ИЛМ должна быть единым интегрированным описанием ПО и отражать потребности всех

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

без изменения ранее определенных.6. В связи с большой размерностью реальных ИЛМ должна обеспечиваться возможностью

композиции и декомпозиции модели.7. Должна легко восприниматься пользователями разных категорий (ИЛМ является средством

коммуникации и конечных пользователей и разработчиков).Компоненты ИЛМ.

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

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

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

между ними.Модель “Сущность – связь” (“С-С”).Модель “С-С” – это неформальная модель предметной области, которая используется на этапе

инфологического проектирования БД. Эта модель позволяет моделировать объекты ПО, взаимоотношения объектов. Другое название модели ER-модель (“сущность” – “Entity”, “связь” – “Relationship”). Используют также название модель “объект-свойство-отношение”, модель “объекты-связи”.

Основные назначения М “С-С” – семантическое описание предметной области и представление информации для обоснованных действий на последующих этапах проектирования БД.

Наиболее наглядным и простым для восприятия и анализа является графические способ отображения М “С-С”. В модели используются три основных конструктивных элемента для предоставления составляющих ПО – сущность, атрибут и связь.

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

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

20

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

Атрибут – это поименованная характеристика сущности, которая принимает значение из некоторого множества значений.

Сущность КНИГА (атрибуты: НАЗВАНИЕ, АВТОР, ГОД_ИЗД).Основное назначение атрибута – описание свойства сущности, а также идентификация экземпляров

сущностей (ШИФР_ДЕТАЛИ – множество уникальных значений шифров деталей – однозначно идентифицирует экземпляр ДЕТАЛИ).

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

Различают связи типа “один к одному” (1:1), “один ко многим” (1:М), “многие ко многим” (M:N).

а) Каждому экземпляру сущности А соответствует один и только один экземпляр сущности В и наоборот. Идентификация экземпляров сущностей уникальна в обоих направлениях для отображения 1:1, т.е. один экземпляр сущности от которого направлена связь, идентифицирует один и только один экземпляр другой сущности и наоборот.

б) Одному экземпляру А соответствует несколько экземпляров В. Однако каждому экземпляру В соответствует только один экземпляр А, т.е. идентификация экземпляров при связи 1:М уникальна только в направлении от В к А.

в) М:1 - обратное отображению 1:М.г) Каждому экземпляру А соответствует несколько экземпляров В и наоборот.Простые и сложные связи взаимоотношений “брак”.

1. Традиционный брак (М ↔ Ж)2. Многоженство (М ←»Ж)3. Многомужество (М «→Ж)4. Шведская семья (М«—» Ж)

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

Простая связь. Одному и тому же экземпляру сущности А соответствует один и тот же экземпляр сущности В. При этом обратная связь не определена.

Многозначная связь. Одному и тому же экземпляру А соответствует несколько экземпляров В. При этом обратная связь не определена.

Во многих случаях интересен не сам факт наличия отношения между сущностями, а свойства этого

отношения. При этом можно рассматривать тип отношения как некий тип сущности со своими описательными атрибутами (ПЕРЕНЕС. ЗАБОЛ: ДАТА, СИМПТОМЫЮ ТЕЧЕНИЕ БОЛЕЗНИ)

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

Обозначения графических элементов:• типы сущностей – прямоугольники; (имя с четким смысловым значением в единственном числе

в именительном падеже);

21

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

• связи (отношения) – ромбы (ромбы соединяются с соответствующими типами сущностей ненаправленными ребрами). Возможно соединение направленными ребрами с указанием типа связи. Связь должна именоваться глаголом или глагольной фразой.

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

Табельный номер

ФИО Специальность Оклад

Номер отдела Название отдела Штатное расписание

Работает Возглавляет

Служащий

Отдел

Выполняется

Проект

Шифр проекта Название Этапы

Моделирование локальных представлений. Моделирование локальных проектных представлений завершается построением ИЛМ локального

представления. Выбор локального представления зависит от масштабов ПО (для удобства проектирования в отдельном лок.пред. – 6-7 типов сущностей). Чаще лок.пред. соответствует внешнему приложению – отдельной функциональной задаче.

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

Этапы моделирования:1) формулирование сущностей,2) выбор идентифицируещего атрибута,3) назначение сущностям описательных атрибутов,4) спецификация связей.

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

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

Рекомендуется проработать несколько вариантов ИЛМ лок.пред.

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

Исходная ИЛМ (недостаток – нет информации о поставщике, который не выполняет поставок в настоящее время). Необходимо ввести сущность – ПОСТАВЩИК.

Целесообразно выделение сущностей: ПОСТАВЩИК, ТОВАР, ПОСТАВКА.2. Выбор идентифицирующего атрибута.

22

Индекс поставки

Индекс поставщика

Адрес поставщика

Индекс товараНазвание

товара

Количество товара

Цена единицы

Шифр склада

Дата поставки

Поставка

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

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

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

4.Спецификация связей.Выявляются

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

Т.о. моделирование лок.пред. заканчивается графическим отображением ER-модели

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

Спецификация для примера:1) Спецификация по сущностям.Типы сущностей: Поставщик; Поставка; Товар.Поставщик: идентификатор – индекс поставщика, описательные атрибуты – адрес поставщика.Поставка: идентификатор – индекс поставки, описательные атрибуты – кол-во, цена единицы …Товар: идентификатор – индекс товара, …2) Спецификация связей.Типы связей: поставляет, может поставлять, может быть поставлен, поставлен.Поставляет: 1:М от Поставщика к Поставке.

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

Update → каскадное изменение индексаDelete → перемещение в архивInsert → RestrictМожет поставлять: многозначная

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

3) Спецификация атрибутов.Индекс_Поставщика: алфавитно-цифровой,

6 символов, например ‘ПОС_99’(значение из домена)

Пример: рассмотрим Типовую инфологию.

1) ИПК директор магазина.Заказы на продажу:а) Номер заказаб) Дата оформления

23

Поставщик

Товар

Поставка

Индекс поставщика

Адрес поставщика

Индекс поставки

Количество товара

м.б. поставлен

может поставлять

поставляет

поставлен

Шифр склада

Дата поставки

ИндексЦена

единицы

Название

Покупатель

СчетЗаказанный

товар

Заказ на продажу

Продавец

Каталог

Склад

ПоставщикЗаказ на оптовую поставку

Магазин

Договор

Поставляемый товар

Оптовый товар

Счет

Накладная

делает оформляет

оплачивается (по счету)

включает

выбирается

продается

поступает

оформляется

выбирается

включает поставляет

заключает

делает

выполняется

поставляет

заключает

в) Товарг) Реквизиты продавца и покупателяд) Сумма1. Бизнес правила:а) невозможна продажа товара из каталога, которого нет на складе.б) если товар отсутствует на складе, то заказ оформляется, но время выполнения заказа

увеличивается на 3 дня (можно, например, наложить санкцию на поставщика, если он не поставил товар вовремя).

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

Поставщик Тип товара Товар

Вводится для упрощения поиска в сотнях тысяч наименований.Возможны 4 варианта реализации склада:1) Реально существующий склад

1. номер склада2. адрес склада3. кладовщик4. помещения5. полки6. для какого товара определены эти полки и помещения.

В накладной прописывается какой товар, в каком количестве поступает, куда помещен и дата поступления, т.е. всё реально!

2) Полуреальный складОтказываемся от номера склада, адреса, кто является кладовщиком, т.е. только накапливаем данные

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

СкладЗаказанный

товар

3) Виртуальный склад.Склада как такового нет, ведется только обработка поступившего и заказанного товара.4) Состояние полуреального и виртуального склада.Т.е. на момент времени (начало месяца) составляет полуреальный склад, далее обработка ведется с

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

сущностей, на уровне сущностей, на уровне связей (самое главное).2) ИПК производства (информационно – программный комплекс).Вариант отличается тем, что мы закупаем комплектующие и собираем товар, который мы будем

продавать.

Покупатель

Заказ на продукцию

Продукция по заказу -конкретно

Комплектующие заказа

Производимая продукция

Комплектация

Склад

(каталог продукции) (спецификация продукта)

забираются (со склада)

выбраны из

включает

состоит из

выбрано из

24

Продукция:

т.е. это ветка Производимая продукция →

комплектация.

Объединение ИЛМ локальных представлений.

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

объединение. При большем числе обычно используется бинарное или попарное объединение.

В состав ИЛМ №1 включено N1 объектов. При попарном объединении в результате получаем объединенный ИЛМ (1 ÷ 2) мы получаем в совокупности (N1+N2-x) объектов, где х – это Х-фактор объединения. Он определяет число идентичных объектов. На конечном шаге мы получим результирующую ИЛМ нашей ПО.

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

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

Введение таких конструкций позволяет:- объединить несущественные различия в представлении подобных объектов- устранить несущественные различия в представлении подобных объектов- ввести абстрактные понятия, удобные для решения задач ПО и установить связи этих понятий с

более конкретными понятиями, использованными в модели. Это позволяет в более правильном и более понятном для реализации виде описать ПО.

- образовать классы и подклассы подобных объектов и ввести соответствующие абстрактные понятия.

При объединении представлений используются три основополагающие концепции: • идентичность, • агрегация, • обобщение.

1. Идентичность. Два или более элементов модели идентичны, если имеют одинаковое

семантическое (смысловое) значение. Идентичность м.б. определена путем объявления двух или более элементов синонимами.

Пример:дисциплина

курс

учебный курс

синонимы

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

25

ПК Комплектующие

Цена

Модель

Характеристики Наименование ТипХарактеристики

Количество

Цена

ИЛМ 1 ИЛМ 2

ИЛМ (1?2)

ИЛМ ПО

N1 N2

ИЛМ(n-1) ИЛМ n

ИЛМ(n-1) ? n

Изделия предприятия

Покупные детали

Детали собственного поизводства

класс

подкласс

подобных объектов, чем идентичных. Поэтому для определения идентичности требуется более глубокая и детальная проработка ПО.

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

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

Пример: Связь между сущностями “Студент”,“Дисциплина”,“Преподаватель”,“Оценка” имеющая смысловое

описание “Студент … получил на экзамене по дисциплине … у преподавателя по фамилии … оценку …”, может быть представлена агрегированным элементом “Экзамен”.

При объединении представлений агрегация встречается в следующих формах:

• В одном ЛП агрегатный объект А определен как единое целое, а во втором – рассматриваются его составные части.

ЛП 1 ЛП 2

Объект А В1В2

В3

При простом объединение мы получили бы совокупность А, В1, В2, В3. Но зная, что объект А включает в свой состав элементы В1, В2, В3 мы можем в результирующее объединение включить объект А и трактовать его т.о., что в его составе имеются элементы В1, В2, В3. При описании ПО отдельные составные части появляются из-за того что пользователь их определяет из-за своих информационных потребностей, а не из-за того, что он не знает, что они входят в другие объекты.

Пример:Целесообразней при объединении этих двух ЛП оставить только один объект велосипед.

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

При объединении создается объект А, в состав которого входят В1, В2, В3, В4 .Пример:

В ЛП1 не можем определить объект, т.к. подобъектов недостаточно, а вместе с ЛП2 - можем.

• Один и тот же объект рассматривается в различных представлениях, но составляющие этого объекта различны.

26

Студент Дисциплина Преподаватель Оценка

Экзамен

ФИО студента ФИО препода Дисциплина Оценка

ЛП 1 ЛП 2

В1В2

В3В1 В2

А

В1 В2 В3 В4

ЛП 1 ЛП 2

колесо

рама

седло руль фара

(заменяемые детали)

(незаменяемые детали)

Велосипед

ЛП 1

А

В1В2

В3

А

В1 В2 В3 В4

А

В1В2

В3

ЛП 2

В5

Пользователь 1 Пользователь 2(продавец) (кладовщик)

- на фабрике велосипедов

ВелосипедРамы Колеса

СиденияРули

Велосипед

рамыседения

колеса

рули

ЛП2

Гарнитур Кисы Воробьянинова

индекс цена

имеет в составе

имеет в составе

имеет в составе

Стул Стол Шкаф

индекс цена индекс цена индекс цена

ЛП2

Пример: ЛП1Эти два ЛП можно объединить. В объединенном объекте “Гарнитур” будут составлены элементы из

обоих ЛП.

3) Обобщение.Обобщение – абстракция данных, которая позволяет трактовать класс различных подобных типов

объектов как один поименованный обобщенный тип объекта.В обобщении подчеркивается общая природа объектов. В случае многоуровневой иерархии

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

Пример: В объединяемых ЛП присутствуют следующие сущности: Детали_собственного_производства, Детали_покупные, Сборочные единицы_покупные, Сборочные единицы_собственного производства.

Объединенное представление.Применение обобщения позволяет организовать для

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

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

гарнитура”.Введем компонент с описательным атрибутом НАИМЕНОВАНИЕ.Окончательный вид объединенного представления:

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

очередь из-за:1) неоднозначности понимания семантики ПО; 2) различиями в представлении ЛП-й разработчиками; 3) ошибок специалистов, которые ведут разработку;

27

Гарнитур генеральши Поповой

название гарантия

дата изготовления

имеет в составе

имеет в составе

имеет в составе

Стул Стол Шкаф

дата изготовления

кто мастер гарантия

Элементы изделий предприятия

Детали (Д)Сборочные

единицы (СЕ)

Д собст. пр-ва

СЕ собст. пр-ва

Д покупные

СЕ покупные

Род

материалразмер

вес

Вид

наследует

материал размер вес

цех изготовления завод изготовитель

видовое отличие

Гарнитураимеет в составе

Компонент

индекс

наименование

цена

количество

4) неполноты описания ЛП-я.Процесс объединения продолжается до тех пор, пока не будет получено обобщенно описание всей

ПО, причем д.б. согласованы и учтены (устранены) все неувязки, которые имели место на этапе объединения.

Пример: дилер. ER-модели широко используются в практике

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

1. Встроенные CASE-системы.2. Универсальные CASE-системы.

1. Встроенные – это те CASE-системы, которые являются принадлежностью программного окружения конкретной СУБД.

Словарь данных – репозиторий.Инфология → даталогия → физическое проектирование.CASE-системы: Oracle, SyBase – эти системы удобны и заточены на ту систему, в которую встроены

(физически).С другой стороны они также дополнены до универсальности.2. Универсальные – предназначены для различных СУБД, они основаны на различных методологиях.а) ERwinб) Silverrunв) Prokitг) Desing/IDFEВсе они имеют графическую оболочку, редакторы для описания ER-модели, удобный

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

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

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

Все эти системы позволяют осуществить последовательный переход от ИЛ-описания к ДЛ-описанию с последующей генерацией БД на физическом уровне (т.е. результат – это прогр. на ЯОД).

Применение CASE-системы ERwin для проектирования БД.CASE-система ERwin изначально была разработана фирмой Logic Works, первая версия →

ориентированная на DOS. В 1998 → слияние с фирмой PLATINUM-Technology, система выпускается под логотипом PLATINUM. В настоящее время приобретена by Computer Associates и выпускается под ее логотипом. Год назад стал выпускаться вместе с другими в All Fjusion.

Эта система включает инструменты для описания ER-модели на ИЛ-уровне , ДЛ-уровне и на физическом уровне. Она ориентированна на разработку большого числа СУБД, т.е. можно разбить ИЛМ и трансформировать в другую (любую) СУБД. Эта CASE-система позволяет делать обратное проектирование (реинженеринг), т.е. по готовой физической БД получать ДЛ-описание и переходить к ИЛ-ии. Реинженеринг позволяет делать переход от одной среды к другой. В частности, при переходе от модели файл-сервера к модели клиент-сервер.

Остановимся на версии 4.1.1) Проектирование БД на ИЛ-м, ДЛ-м и физическом уровне с применением удобного и

дружественного графического инструментария.2) Прямое подключение к БД, т.е. создание БД непосредственно из Erwin’а и восстановление

модели БД по физической структуре.3) Переход от одной целевой БД к другой с использованием взаимнооднозначного соответствия в

особенностях СУБД.4) Поддержка настольных (десктоп) СУБД.

28

Покупатель Заказ Дилер

Заказанный товар

Заказанный оптовый

товар

Оптовый заказ

Производитель

5) Управление физическими характеристиками СУБД (настройка параметров физического хранения)

6) Возможность фрагментарного разбиения всей БД на отдельные функционально законченные логические блоки (области).

7) Процедуры и триггеры, которые описываются на этапе проектирования БД, создаются автоматически при генерации БД.

8) Возможность хранения описания БД в целевой БД или в отдельных dbf-файлах.9) Достаточно обширные развитые средства документирования ER-модели и автоматическая

генерация отчетов в различных средах.Реализация моделирования в системе ERwin осуществляется на основе теории реляционных баз и

методологии IDEF1x. Эта методология первоначально была разработана в США и была ориентированна на использование в ВВС для работы с БД. В настоящее время она широко используется как федеральный стандарт в США.

Методология IDEF1x определяет стандарты терминологии, которые используются при моделировании, стандарты на графические отображения компонентов, в частности на этапе описания ИЛ-ии – описании сущностей атрибутов и связей, а также на целый ряд, который используется при моделировании. В отличие от общепринятого 3х этапного процесса проектирования, в ERwin выделяют только 2.

- уровень логического моделирования ― ИЛМ.- уровень физического моделирования ― ДЛМ + физическая модель.

Моделирование БД:1. Определение сущностей.2. Определение зависимостей между сущностями.3. Задание первичных и альтернативных ключей.4. Описание атрибутов сущностей.5. Описание ограничения целостности.6. Приведение модели к требуемому уровню нормализации данных.7. Преобразование ER-модели в модель ДЛ-уровня, т.е. необходимо определить соответствия

между:а) имя сущности ↔ имя отношенияб) имя атрибута ↔ имя поляв) имя связи ↔ имя связи между таблицамитакже д.б. задание процедур, триггеров и ссылочной целостности.

8. Переход к физическому уровню: задание параметров хранения данных.9. Генерация программного кода.

1-4 шаги трактуются как ИЛ-моделирование. 6-7 как ДЛ.ERwin является средством визуализации моделирования, что позволяет использовать разработанную

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

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

ERwin система интегрирована с целым рядом популярных средств разработки приложений. Например: Power Builder, Visual Basic, Delphi. Это позволяет находясь в системе автоматически сгенерировать код приложения и проверить его при работе с разработанной структурой базы данных.

ERwin поддерживает прямой интерфейс со следующими СУБД:1) DB2 (IBM, аппаратно0программный продукт)2) Informix3) Ingres4) Netware SQL5) Oracle6) Progres

29

ERwin

IDEF1x

СУБД

1. Power Builder

2.Visual Base

3. Delphi

Среды программирования

7) SQL/4008) SQL Base9) Microsoft WQL Server10) Sybase11) Ststem 1012) Watcom SQL

Настольный СУБД:1. Access2. FoxPro3. Clipper4. dBase5. Paradox

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

Основные преимущества CASE-систем типа ERwin:1) Существенное повышение скорости разработки за счет мощного редактора диаграмм,

автоматической генерации программного кода и элементов управления.2) Нет необходимости в ручной подготовке SQL-кода для создания БД.3) Возможность легкого внесения изменений на различных этапах проектирования в процессе

модификации и расширения БД.4) Возможность автоматической подготовки отчетов по БД и все эти отчеты являются

актуальными и соответствуют реальной структуре БД.5) Разработчики приложений снабжены удобным средством описания структуры БД и целый ряд

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

6) Тесная интеграция со средствами разработки приложений, которые позволяют тестировать БД на стадии разработки.

7) Возможность реинженеринга системы, с возможностью документирования системы.8) Поддерживание большого набора персональных БД обеспечивает возможность перехода от

одной модели к другой, более расширенной и функциональной.

Модели данных ДЛ-уровня.В информационных системах, в памяти ЭВМ поддерживается (отображается) модель ПО. Результат

моделирования ПО зависит не только от самой ПО, но также и от конкретной СУБД, т.к. она предоставляет инструментарий для отображений ПО. Т.о. при ДЛ-моделировании рассматриваются модели данных, которые представляют конкретная СУБД в качестве инструментария для отображения ПО.

Инструментарий → модель данныхРезультат использования инструментария → модель БДМодель данных ДЛ-уровня определяется тремя компонентами:

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

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

Пример: СУБД ОКА:Ограничения на типы и количества:

1) количество типов не более 256 (типов записей)2) числа полей – не более 1000

Между записями устанавливается иерархические связи, число уровней этих связей – не более 15, т.е. ограничение на количество уровней иерархии.

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

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

30

Сюда в первую очередь входят операции по выборке данных и операции по изменению состояния БД.

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

Эти три компонента характеризуют сам инструментарий. Традиционно используется три модели данных: 1) сетевая; 2) иерархическая; 3) реляционная.

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

под названием Кодасил, т.е. этот проект определял первый вариант сетевой модели.Сетевые СУБД, содержащие подмножества этой модели:Сектор, Банк, Сеть, dbVista (для РС)Модель Кодасил предусматривает:1. Организация данных и ограничения целостности.Организация данных в сетевой модели определяется в следующих терминах:

1) элемент2) агрегат3) запись4) база данных5) групповое отношение1) Элемент данных – наименьшая единица структуры, каждому элементу присваивается

уникальное имя при описании БД.2) Агрегат данных – это именованная совокупность элементов или других агрегатов данных.

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

3) Запись – это агрегат, который не входит в состав других агрегатов и составляет основную единицу обработки данных. Применительно к записи имеют место характеристики:Тип записи – определяет состав её элементов и агрегатов.Если запись содержит несколько значений элемента одного тип, то говорят, что в такой записи определен вектор. Количество значений в векторе определяет его длину. Различают векторы с фиксированной длиной и векторы с переменной длиной.Т.о. в общем случае мы имеем ту структуру записи, которую уже рассматривали:Либо:

элемент вектор агрегат повторяющийся агрегат

для сетевой модели

Сложность записи должна поддерживаться функционально в среде СУБД. В реляционной модели запись состоит только из элементов (только простые элементы, не составные).

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

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

31

Житель Клиника

диспансеризация

групповое отношение

владелец подчиненный

обмен

Пример:Как было отмечено, групповое отношение является

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

поликлиника организация

жительСбербанк

Сберкнижка

владалец

основная работа

диспансерзация

вкладывладалец

нокопления

подчиненный

подчиненный

владалец

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

В экземпляр Иванов могут входить типы Дочь и Сын.Каждый тип гр.отн-я характеризуется следующими признаками:

(1) Способом упорядочивания подчиненных записей.(2) Способом (режимом) включения подчиненных записей.(3) Режимом исключения подчиненных записей.

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

подчиненных записей, которые поставлены в соответствии с некоторой записью владельца.

Варианты упорядочивания:1. хронологически, т.е. в порядке поступления.2. обратно хронологически.3. сортировка подчиненных записей (обычно традиционно) по ключу.

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

(2) Режим включения принимает два значения: автоматический и ручной.1. При автоматическом режиме подчиненная запись включается в гр.отн-ие одновременно с

запоминанием путём её закрепления за записью-владельцем. При этом запись-владелец должна быть помещена в БД заранее.

2. При ручном включении позволяется запомнить подчиненную запись в БД, не включая ее немедленно в гр.отн-ие. Эта операция выполняется позже вручную. При этом допускается появление записей-владельцев позже, чем включена подчиненная запись.

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

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

1. Фиксированный класс членства.

32

поликлиника

Иванов Петров Сидоров

№51

поликлиника№13

один экземпляр группового отношения

другой экземпляр

Иванов

дочь1 дочь2 сын1 сын2

житель

дочь сын

дети

Подчиненная запись жестко закреплена за записью-владельцем. Она не может существовать без записи-владельца. Ее можно исключить из гр.отн-ия только путем её удаления из БД. При удалении записи-владельца одновременно с ним удаляются подчиненные записи.

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

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

3. Необязательное членство.Позволяет исключать подчиненную запись из гр.отн-ия, сохраняя при этом подчиненную запись в

БД и не прикрепляя её к другому владельцу.Рассмотренные гр.отн-ия позволяют моделировать достаточно сложные ПО и устанавливать между

объектами сложные взаимосвязи, имеющими место в ПО.Операции над данными в сетевой модели:

1) Операция “Запомнить” – позволяет занести в БД новую запись и автоматически включить эту запись в гр.отн-ие, где она будет объявлена подчиненной записью с соответствующим режимом включения.

2) Операция “Переключить” – позволяет связать подчиненную запись с записью-владельцем в том же гр.отн-ии.

3) Операция “Обновить” – позволяет изменить значения полей записей в БД.4) Операция “Извлечь” – позволяет извлечь одну или совокупность записей по значению ключа

или используя переход по гр.отн-ию, т.е. от владельца к члену и наоборот.5) Операция “Удалить” – предоставляет возможность удаления ненужных записей из БД, при

этом в обязательном порядке анализируется класс членства подчиненных записей.6) Операция “Исключить из гр.отн-ия” – позволяет разорвать связь между записью-владельцем и

подчиненной записью, но при этом сохранить обе записи в БД.

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

структуре БД.3. От извлеченной записи возможны переходы как к её подчиненным записям, так и к тем

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

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

Иерархическая модель данных.Иерархические модели данных поддерживаются следующими промышленными СУБД: IMS, OKA, ИНЕС, БАНК.Структура данных модели описывается в тех же терминах, что и сетевая модель, а именно: элемент,

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

древовидную структуру. Совокупность корневой записи и множества подчиненных ей записей других типов называют деревом. Число деревьев в БД определяется количеством корневых записей или записей верхнего уровня.

пример экземпляра, → соответствующего ←структурной схеме.

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

33

А1

В1 В2 В3 Н1 Н2

М1 М2 М3 М4 М5 Е4 Е5Е1 Е2 Е3

запись верхнего уровня

А

В Н

М Е

1й уровень

2й

3й

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

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

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

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

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

Пример:поликлиника организация Сбербанк

житель

Сберкнижка

сетевая структура

поликлиника организация Сбербанк

поциент сотрудник вкладчик

Сберкнижка

фио фио фио

ключ – № страх.полиса

ключ – № паспорта

иерархическая структура

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

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

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

Операции над данными в иерархической модели:1) Операция “Запомнить” – позволяет занести в БД новую запись. Для корневой записи

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

2) Операция “Обновить” – позволяет изменить значения полей предварительно выбранной записи. При этом не должны изменяться ключевые значения.

3) Операция “Удалить” служит для удаления ненужных записей и всей совокупности подчиненных ей записей.

4) Операция “Извлечь” имеет целый ряд модификаций:1. GU – Get Unique - получить уникальный2. GN – Get Next – получить следующий3. GNP – Get Next Parent – получить следующий под исходным4. GHU – Get Hold Unique – получить и удержать5. GHN – –––––––– ″ ––––––––6. GHNP – –––––––– ″ ––––––––

Результатом выполнения одной из команд извлечь является перенесение в рабочую область прикладной программы экземпляра или экземпляров сегмента. Если операция извлечения прошла успешно, то в специальную область, доступную прикладной команде помещается соответствующий код состояния команды.1) Оператор Get Unique предназначен для извлечения сегмента независимо от значения

текущего состояния в БД. При использовании этой команды поиск ведется начиная с корневого сегмента до экземпляра сегмента, который удовлетворяет заданному условию.

2) Оператор Get Next обеспечивает выборку следующего экземпляра сегмента в логической последовательности базы данных. При этом следующий трактуется как левосторонний обход иерархического дерева.

34

А1

В1 В2 В3

М1 М2 М3 М4 М5

левосторонний обход дерева

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

Каждый из операторов может включать в свой состав т.н. оператор поиска (или предложение классификации SSA). SSA определяет имя сегмента и может включать разные условия, которым должен удовлетворять извлеченный экземпляр сегмента. При этом условия м.б. простыми или сложными и включать логические условия И, ИЛИ, НЕ.

GU HOSP(HOSP.N=№30)PALATA(PAL_N= “Кардиология”)PACIENT(PAC.N= “Петров”)Вывести список пациентов хирургии:GU HOSP(HOSP.N=№30)

PALATA(PAL_N= “Хирургия”)GNP → будем перебирать пациентов4) Оператор Get Hold Unique определяет

выборку и удержание записи; записи, выбранные с помощью Hold затем м.б. модифицированы или удалены.

Отличительные черты иерархической модели:1. Данные организованы в иерархические структуры.2. При отображении сетевых структур в иерархическую модель необходимо дублирование

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

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

Реляционная модель данных.Концепция реляционной модели связана с именем известного специалиста в области теории БД

Эдварда Кодда. В 1910 г. сформулировал основные понятия и ограничения, которые присущи этой модели. Самое слово “реляционное” происходит от англ. Слова ”relation” – отношение. В основе реляционной модели используется математическое понятие “отношение”, которое формулируется как подмножество декартова произведения доменов.

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

Декартовым произведением доменов Д1, Д2, … ,Дк

1 2 ... кД Д Д Д= × × × Где Д1 – множество, { }11 11 12 1, ,..., nД d d d=

Д2 – множество, { }22 21 22 2, ,..., nД d d d=

ДК – множество, { }1 2, ,...,kK K K KnД d d d=

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

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

35

Больница № 30

палата №2 | кардиология

пациентИванов | инфарктПетров | инсульт

Мерин | кровонимияпалата №5 |

хирургияпациент

Больница № 45

палата №3 |

пациент

1

2

3

456

7

89

1011

12

13

Перебор в определенной последовательности: фиксируем (k-1) элементов и последовательно добавляем каждый из элементов k-того домена.

1

2

1 1

11 21 1

11 21 2

11 21

11 2

12 2

1 2

...

...

... ... ... ...

...

...

...

... .... ... ...

...

k

k

k

k

k

k

kn

n kn

n kn

n n kn

d d d

d d d

d d dД

d d d

d d d

d d d

=

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

Пример:

{ }{ }{ }

( ) ( ) ( ) ( ) ( ) ( )( ) ( ) ( ) ( ) ( ) ( )

1

2

3

1 2 3

, 2

,

4,5,

3

, , 4 , , ,5 , , , , , , 4 , , ,5 , , , ,

2, , 4 , 2, ,5 , 2, , , 2, , 4 , 2, ,5 , 2, ,

Д А

Д В С

Д Д

k

А В А В А В Д А С А С А С ДД Д Д Д

В В В Д С С С Д

=

=

==

= × × =

графическое ↑

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

т.е. рассматриваемых доменов. Отношением R на множестве доменов Д1, Д2, … ,Дк называется подмножество декартова

произведения доменов: 1 2 ... КRД Д Д⊆ × × ×Элементами декартова произведения являются кортежи, следовательно элементами отношения

являются также кортежи. Число k определяет арность кортежа, т.е. сколько элементов входит в кортеж. Арность кортежа определяет и арность отношения или его степень, т.е. говорят, отношение арности k.

Отношение есть множество и поэтому в нем не должны встречаться одинаковые кортежи. Порядок кортежей в отношении не существенен.

Пример1: отношения для 1 2 3Д Д Д× ×

( ) ( ){ }1 1 2 3, , 4 , , , 4RА В А С Д Д Д= ⊆ × ×

( ){ }2 1 2 32, ,RС Д Д Д Д= ⊆ × ×

{ }3 1 2 3..............RД Д Д= ≡ × × , где { }.............. - полное декартово произведение

4 0R = - пустое отношениеПример2: три домена

36

Д1А | 2

Д3В | С

Д2В | С

4 | 5 | Д 4 | 5 | Д

А |

В |

4

А |

В |

5

А |

В |

Д

Д3Д3

{ }{ }{ }

1

2

3

, ,

,

3, 4,5

Д Иванов Петров Сидоров

Д САУ БД

Д

=

=

=Полное произведение доменов включает 18 кортежей из трех элементов.

( ) ( ) ( ){ }1 2 3 , ,3 , , , 4 , , ,5 ,...Д Д Д Д Иванов САУ Иванов САУ Иванов САУ= × × =Отношением на этом декартовом произведении мы промоделируем реальную ситуацию, а именно

итоги весенней сессии для этих студентов, в состав которых включим 4 тройки( ) ( ) ( ) ( ) ( ){ }, ,3 , , ,3 , , , 4 , , ,3 , , ,3RИванов САУ Иванов БД Петров САУ Петров БД Сидор ов САУ=

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

Пример: R1 R2 R3

А В 4А С 4 2 С Д

2 С ДА В 52 В Д

Таблица, которая представляет k-арное отношение, обладает следующими свойствами:1) Каждая строка – кортеж из k элементов, принадлежащий k столбцам.2) Порядок столбцов в таблице строго фиксирован, т.е. 1,2,3…k.3) Порядок кортежей (или строк в таблице) безразличен.4) Любые два кортежа различаются хотя бы одним элементом.5) Строки и столбцы таблицы могут обрабатываться в любой последовательности.

Использование понятия отношения для представления данных.Математическое отношение используется для представления данных двояко. 1) Во-первых, для

представления набора объектов. При этом под набором объектов понимают множество подобных объектов. 2) Во-вторых, для представления связей между наборами объектов.

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

Несколько атрибутов отношения м.б. определены на одном и том же домене: рассмотрим отношение:

Атрибуты различных отношений

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

Пример: для таблицы “Деталь” – это один атрибут номер детали.

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

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

37

номер детали название количество вес, кг материал127-47А втулка 12000 0,8 сталь581-93С педаль 10000 1 сталь253-3К тормоз 11000 0,5 алюминий531-1К крыло 300 0,7 пластмасса

кортежи появление значения из заданного домена:

Доменстальалюмпластм.

Имя Страна год рожд. год смертиПетрарка Италия 1304 1374

Гёте Германия 1749 1832Байрон Англия 1788 1824

атрибут доменодин домен –

“год”

ПОЭТ

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

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

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

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

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

Операции над данными.1) Операция “Включить” требует задания имени отношения и атрибутов, характеризующих

кортеж. При этом обязательно задание ключа.2) Операция “Удалить” также требует знания имени отношения, а также необходима

идентификация кортежа или кортежей, которые удаляются из кортежей.3) Операция “Обновить” выполняется для заданного кортежа или набора кортежей.

Т.о. в реляционной модели операции исполняются не над записями, а над отношениями.

Основные операции обработки отношений.Единицей обработки этих операций является не кортеж, а отношения. Т.о. на входе каждой операции

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

(1) Операция “объединение” 1С А В= ∪Предполагается, что на входе имеются два односхемных отношения А и В. Результирующее

отношение С1 построено по той же схеме и включает в свой состав все кортежи отношений А и В.Пример: А (Сбербанки Выборгского района) В (Сбербанки ВО)номер район адрес

2106 Выборгский Художников, 132184 Выборгский Муринский, 85

номер район адрес3045 Вас.остр. Средний, 195046 Вас.остр. Большой, 36

1С А В= ∪номер район адрес

2106 Выборгский Художников, 132184 Выборгский Муринский, 853045 Вас.остр. Средний, 195046 Вас.остр. Большой, 36

(2) Операция “пересечение” 2С А В= ∩Предполагается, что на входе также имеется два односхемных отношения. Результирующее

отношение построено по той же схеме и содержит только те кортежи отношения А, которые есть в отношении В.Пример: А (пациенты поликлиники №59) В (сотрудники БГТУ)

ФИО адрес ФИО адрес

С2 (сотрудникик БГТУ, прикрепленные к поликлинике № 59)ФИО адрес

38

номер адрес тел.глав.в

рачнаим. ведомство адрес тел.

организацияполиклиника

житель

Сбербанк

сберкнижка

кортеж

ФИО№

поликл.наимен.

организациитабельный

номерадрес тел.

№ банка

№ счета ФИО

номер район адрес

сумма вклад

(3) Операция “вычитание” 3С А В= −Все три отношения также построены по одной схеме. В состав результирующего отношения включаются только те кортежи из отношения А, которых нет в отношении В.Пример:

А – сведения о всех жителях района.В – сведения о жителях района, которые прошли диспансеризацию в 2005 г.С3 – сведения о жителях района, которые не прошли диспансеризацию.

(4) Операция “декартово произведение” 4С А В= ×Если отношение А имеет арность k1, а отношение В имеет арность k2, то результирующее отношение

С4 будет иметь арность k1+k2, причем первые k1 элементов берутся из отношения А, а последние k2

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

дисциплина дата оценкамат.анализ 10.янвин.яз. 20.янв

С4 (экзаменационная ведомость)Имя дисциплина дата оценка

Иванов мат.анализ 10.янвПетров мат.анализ 10.янвИванов ин.яз. 20.янвПетров ин.яз. 20.янв

(5) Операция “выборка” (“горизонтальное подмножество”)На входе данной операции используется только одно отношение. Результирующим является

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

(6) Операция “проекция” (“вертикальное подмножество”)На входе имеется одно отношение. Результирующее отношение включает подмножество атрибутов

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

ФИО № поликлиники наименование организацииИванов 13 ГИДУВ

Сидоров 13 ГИДУВКоровин 59 ЛОМОТеликов 13 БГТУПетров 13 ЛОМОМухин 59 ГИДУВ

Травкин 13 БГТУ

Необходимо построить проекцию отношения “жители” на два атрибута – номер поликлиники и наименование организации:№ поликлиники наименование организации

13 ГИДУВ59 ЛОМО13 БГТУ59 ГИДУВ13 ЛОМО

(7) Операция “соединение”На входе используются два отношения А и В. В каждом из отношений выделен атрибут, по

которому производится соединение отношений (пусть в А это А1, а в В - В1). Обязательно эти

39

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

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

Пример: А (отношений Сбербанк) В (сберкнижка)

номер район адрес2103 Выборгский Художников, 133012 Выборгский Муринский, 598105 ВО Детский, 508100 ВО Средний, 13

№ СбБанка № счета ФИО сумма тип вклада3012 5010 Иванов 15000 срочный4456 1128 Акулов 20000 выигрышный8105 2615 Терехов 800 срочный8216 3051 Петров 30000 обычный8105 1000 Кулагин … …

Необходимо произвести соединение этих двух отношений по атрибуту № Сбербанка. Результирующее отношение будет построено по схеме (k1+k2-1), и будет включать:

только для А1=В1

№ СбБанка район адрес № счета ФИО сумма тип вклада3012 Выборгский Муринский, 59 5010 Иванов 15000 срочный8105 ВО Детский, 50 2615 Терехов 800 срочный8105 ВО Детский, 50 1000 Кулагие ……..

(8) Операция “деление”На входе также два отношения – А и В.А - делимое; В – делитель.Пусть в состав атрибутов отношения А входят атрибуты 1 2, ,..., nА А А , и в состав отношения В входят

атрибуты 1 2, ,..., КА А А , причем k<n, т.е. это подмножество атрибутов отношения А. Результирующее

отношение C определено на атрибутах 1 2, ,...,K K nА А А+ + , и в состав кортежей результирующего отношения включаются только те кортежи декартово произведение которых с кортежами отношения В содержится в отношении А, т.е. кортеж включается только в том случае, если декартово произведение входит в состав А. Пример: А (делимое) – экземпляр ведомости. В (делитель) – результат сессии

студент дисциплина оценкаИванов мат.анализ отл.Иванов ин.яз. хор.Терехов мат.анализ хор.Терехов ин.яз. отл.Телегин мат.анализ отл.Телегин ин.яз. хор.

дисциплина оценкамат.анализ отл.ин.яз. хор.

С – результирующее отношениестудентИвановТелегин

Пример:Рассмотрим пример использования операций над отношениями для обработки отношений. В состав

БД входят следующие отношения:Необходимо выдать список пациентов поликлиники

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

40

номер адрес тел.глав.в

рач

поликлиника

район

наим. ведомство адрес тел.

организация

житель

ФИО№

поликл.наимен.

организациитабельный

номерадрес тел.

№ поликл.

адрес ФИОнаимен.

организации

1. Операция Выборка из отношения Поликлиника по условию район = ВО, получаем отношение R1.

2. Операция Соединение: R1 с отношением Жители по атрибуту № поликлиники. Результат → R2 (в него войдут все жители прикрепленные к поликлиникам ВО района).

3. Соединение: R2 с отношением Организация по атрибуту Наименование организации, результат → R3. Мощность будет такая же, как и R2 .

4. Проекция отношения R3 на атрибуты № поликлиники, адрес поликлиники, ФИО пациента, наименование организации → R (результат).

Рассмотренные операции обработки отношений составляют операции т.н. реляционной алгебры.

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

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

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

Особенности реляционной модели:• Множество объектов реляционной модели однородны. Структура данных определяется только

в терминах отношений.• Основная единица обработки в реляционной модели не запись, как это было для сетевой и

иерархической модели, а отношение.В общем ЯМД реляционной модели выходит за рамки тех операций, которые были определены в

реляционной алгебре. В дополнение к рассмотренным операциям в ЯМД включаются следующие возможности:• арифметические выражения и сравнения могут включаться в операторы реляционной алгебры, в

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

единственных значений функций в виде минимума, максимума, среднего, суммы и т.д.

Два подхода к проектированию даталогической схемы БД реляционной СУБД.Применительно к реляционной модели данных традиционно выделяют два подхода к

проектированию ДЛ-схемы.Первый, классический, который был предложен основоположником реляционной модели Эдвардом

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

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

В отличие от подхода Кодда, данный этап нормализации применяется уже в упрощенном виде и к упрошенным схемам отношений, что не приводит в конечном счете к существенным структурным

41

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

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

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

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

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

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

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

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

В теории реляционных БД обычно выделяют следующую последовательность нормальных форм:1) 1-я нормальная форма 1NF2) 2-я нормальная форма 2NF3) 3-я нормальная форма 3NF4) улучшенная 3-я нормальная форма (Бойса – Кодда) NF BCNF5) 4-я нормальная форма 4NF6) 5-я нормальная форма 5NF

Основные свойства нормальных форм.1) Каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей

нормальной формы.2) При переходе к следующей нормальной форме все свойства передыдущей нормальной формы

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

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

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

Определение 1: Функциональная зависимость.В отношении R атрибут Y функционально зависит от атрибута X, причем эти атрибуты могут быть и

составными, в том, и только в том случае, если каждому значению X в точности соответствует одно значение Y.

R.X(r)R.YX→Y

Пример:

42

1) табличный номер ↔ фамилия2) ФМО → номер комнаты3) Номер комнаты → номер телефона

Определение 2: Полная функциональная зависимость.Функциональная зависимость R.X(r)R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X. Точным подмножеством множества Х называют любое его подмножество, несовпадающее с Х.

Определение 3: Транзитивная функциональная зависимость.Функциональная зависимость R.X(r)R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости: R.X(r)R. Z и R .Z (r)R.Y

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

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

Определение 6: Взаимно независимые атрибуты.Два или более атрибутов называются взаимно независимыми, если ни один из этих атрибутов не является функционально зависимым от других атрибутов.

Вторая нормальная форма. (2 NF )

Пример: конструкторское бюро.

сотрудник задание

проектотдел

№ задания№ сотрудника сотрудник з/п

№ отдела № проекта

выполняется

выполняется

входитработает

Отношение Сотрудник-Отдел-Проект:сотрудник_наим сотрудник_зарпл отдел_ном проект_ном сотрудник_задание

325 5500 10 А-183 ЭП-8325 5500 10 А-200 РП-5130 4500 20 А-200 ЭП-8280 6500 30 А-400 ЭП-5280 6500 30 А-200 ЭП-5280 6500 30 А-183 РП-10

составной ключ (первичный)

РП - рабочий проектЭП - эскизный проект

Ключ: сотрудник_ном, проект_ном.Функциональные зависимости:Сотрудник_ном (r) Сотрудник_зарплатаСотрудник_ном (r) Отдел_номОтдел_ном (r) Сотрудник_зарплатаСотрудник_ном, проект_ном (r) Сотрудник_заданиеОт составного ключа функционально зависит только один атрибут. А остальные атрибуты зависят от

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

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

2) удаляя сотрудника из отношения мы разрываем не только связь сотрудника с конкретным проектом, но и разрываем связь с отделом, в котором он работает. Т.е. мы лишаемся информации об отделе, в котором работает сотрудник.

43

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

4) в данном отношении имеется дублирование информации.Такие аномалии устраняются путем нормализации отношения – переход к нескольким отношениям.Выделяем те атрибуты, которые зависят от части первичного ключа (сотрудник_ном):1) отношение “сотрудник - отдел”сотрудник_ном сотрудник_зарп отдел_ном

325 5500 10130 4500 20280 6500 30

Т.о. это выделение осуществляется путем декомпозиции с использованием операции проекции на выбранные атрибуты.

2) отношение “сотрудник - проект”сотрудник_ном проект_ном сотрудник_задание

325 А-128 ЭП-8325 А-200 РП-5130 А-200 ЭП-8280 А-400 ЭП-5280 А-200 ЭП-5280 А-183 РП-10

Функциональные зависимости:1) Сотрудник-отделПервичный ключ – Струдник_ном- Сотрудник_ном (r) Сотрудник_зарп- Сотрудник_ном (r) Отдел_ном- Отдел_ном (r) Сотрудник_зарп2) Сотрудник-проектПервичный ключ – Сотрудник_ном, Проект_ном- Сотрудник_ном, Проект_ном (r) Сотрудник_заданиеПутем декомпозиции исходного отношения мы получили два отношения, которые имеют лучшие

свойства по сравнению с предыдущим. Решается следующие аномалии; 1), 2), 3), 4). Т.о. мы перешли во вторую нормальную форму.

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

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

Третья нормальная форма.Рассмотрим отношение “Сотрудник-отдел”. В этом отношении мы можем увидеть, что для него

характерным является транзитивная зависимость:х к y: R.X (r) R.Y X – сотрудник_ном

R.Z (r) R.Y Y – сотрудник_зарпZ – отдел_ном

Такая зависимость определяет то, что з/п сотрудника зависит не от его номера, а от отдела в которм он работает. Для этого отношения также имеют место аномалии:

1) мы не сможем ввести з/п отдела до тех пор, пока не появится хотя бы один из сотрудников, который работает в этом отделе, т.к. в этом случае ключ – будет неопределен.

2) при удалении последнего сотрудника из отдела мы лишаемся информации о з/п отдела.3) для того, чтобы изменить з/п отдела, придется выбирать всех сотрудников, которые работают в

этом отделе.Т.о. для этого отношения существуют также аномалии. Для их исключения требуется перевод в

третью н.ф.

44

Определение 8: Третья нормальная форма.Отношение R находится в III н.ф. в том и только том случае, если она находится во II н.ф., и

каждый неключевой атрибут нетранзитивно зависит от первичного ключа.Определение 9: Третья н.ф. (номер 2)

Отношение R находится в III н.ф. в том и только том случае, если она находится во II н.ф. и все неключевые атрибуты независимы.

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

10 550020 450030 650040 10000

сотрудник_ном отдел_ном325 10130 20280 30

Ключ: отдел_ном Ключ: сотрудник_номФункц. зав-сть: отдел_ном (r) сотрудник_зарп Функц. зав-сть: сотрудник_ном (r) отдел_номПример1:

табельный № ФИО оклад комната телефон211 Иванов 3500 12 616358 Телегин 1700 12 616380 Кошкин 4500 5 306

комната телефон12 6165 306

Пример2:№сотрудника ФИО код_специальности должность

225 Петров 4451 инженер328 Сидоров 8881 ст.инженер451 Иванов 981 программист

f( ) – м.б.

Практические рекомендации при переходе от ИЛМ-схемы к реляционной модели.Имеется 8 вариантов переходи от инфологии к даталогии. Они основаны на получение

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

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

Пример: ФИО № зач. № гр.

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

R1 R2R3

ФИО № зач. № гр.

№ яз. Ин.яз.

№ яз. Ин.прогр.

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

1. если многие из объектов обладают рассматриваемыми свойствами, то его можно хранить также как и обычное свойство.

45

студент

ФИО № зач. № гр.

студентФИО

№ зач.№ гр. Ин.яз.

язык прог-я

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

Пример: 1) R1код ФИО индекс страна город

2) R1код_сотрудника ФИО

R2код_сотрудника ВУЗ специальность уч.степень

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

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

Пример: личность ин.яз.

М:1

1) ПО “Завод”. Для данной ПО характерным является то, что некоторые сотрудники знают ин.язык. Но ни один из них не владеет более чем одним иностранным языком, т.е. это говорит о том, что имеется много ин.языков, которыми не владеют работники завода.

Т.о. имеют место определенные условия на отсутствие связей на отдельные экземпляры сущностей.

2) ПО “абитуриент” - каждый абитуриент должен знать один ин.язык, но никто не владеет более чем одним языком.

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

3) ПО “ВУЗ языков” (лингвистический ВУЗ)

студент | языки

4) ПО “Лингвистический институт”

(препод) (есть хотя бы один преподаватель для каждого языка)

5) студент | | курсовик1:1 Связь 1:1 и класс принадлежности в обоих случаях обязателен, значит

можно в одно отношение.ФИО группа ст-т вариант оценка

Для упрощения работы возможно разбиение на R1 R2

46

сотрудник

ФИОкод

страныадрес

индекс

страна

город

высшее образование

ВУЗ

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

уч.степень

Я1

Я2

Я3

Я4Я5

Л1

Л2

Л3

Л4Л5

Я6Л6

Я1 (японский)

Я2

Я3 (английский)

Я4Я5

Л1

Л2

Л3

Л4Л5

Личности: Языки:

абитуриент | ин.яз.

обязательная связь

сотрудник | языки

ФИО группа ст-т ФИО вариант оценка

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

Пример: студент | работа СНО1:1СНО – студенческое научное общество.

ФИО группа специальность вариант оценка

ФИО вариант оценкаR3

R1 R2

Вариант 6. Если связь между объектами 1:М и класс принадлежности n-связной сущности является обязательным, то можно использовать два отношения: первое для описания родительской сущности, второе для описания подчиненной сущности, причем в это отношение добавляются идентификатор связи с родительской сущностью.

Пример: | студентгруппа

R1 R2№ группы специальность староста № студента ФИО № группы

№ группы для связи.Вариант 7. Если связь между сущностями один ко многим и класс принадлежности n-связной

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

Пример: студент

добровоольное общество

1:М

R1(общество) R2(ст-т) R3(связь)название адрес начальник ФИО адрес название ФИО

Вариант 8. Если между объектами установлена связь М:М, то при переходе к реляционной модели используется три отношения:

1) для описания первой сущности2) для описания второй сущности3) включает ключи связи.

Пример: покупатель товар

M:N

R1(покупатель) R2(товар) R3(связи-ключи)код_покупателя ФИО адрес код наименование цена код_покупки код_товара

Язык SQL. – структурированный язык запросов.Появление языка SQL связано с теми теоретическими предпосылками, которые были заложены в

реляционную модель, а именно реляционной алгеброй и реляционным исчислением отношений.Прообраз – в 1970г. – проект System IR → IBM.Язык SQL стандартизирован. Его стандарт выполнен комитетом по стандартизации ANSI и ISO.ORACLE – 1979г. первая коммерческая реализация.Этапы стандартизации SQL :

47

начальное представление

SQLстандарт SQL-86 SQL-89

(SQL-2)SQL-92

SQL3SQL-99 SQL-2003

1984 1986 1989 (+ссыл. цел-сть)

1992 значительные изменения в стандарте

1999 включение

ООП

2003 дополнения по процедурным расширениям

Каждая СУБД реализует какое-то подмножество какого-либо стандарта SQL. Ближе всех к 1992 → Microsoft SQL.

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

Наиболее важные операции в SQL : 1) Операторы определения данных.DDL – Data Definition Language

CREATE → СоздатьDATABASE (БД)TABLE (таблицу)VIEW (представление; индекс; триггер).

DROP → УничтожитьALTER →модифицировать

2) Операторы выборки.DQL → Data Query LangSELECT – Выбрать

3) Операторы манипулирования ( DMP ) INSERT → ВставитьUPDATE → МодифицироватьDELETE → Удалить

4) Средства администрированияGRANT → Предоставить привилегию юзеру.REVOKE → отменить привилегия юзера.

5) Управление транзакциямиCOMMIT → зафиксировать текущую транзакцию.ROLLBACK → прервать текущую транзакцию

(1) Оператор CREATE – позволяет создавать компоненты базы данных (БД, таблиц, индексов, представлений, триггеров).1) Создание базы данных.

CREATE DATABASE <имя БД>2) Создание таблицы

CREATE TABLE <имя таблицы>(<имя столбца><тип данных>[,<имя столбца><тип данных>])Пример : CREATE TABLE student (FIO(c30), GR(c4) VES(I))3) Создание индекса

CREATE [UNIQUE] INDEX <имя индекса> ON <имя таблицы> (<имя столбца>[ASC|DESC] [,<имя столбца>[ ASC |DECS ] )

если составной индексПример : CREATE UNIQUE INDEX stud ON student (FIO) (FIO, Gr)

(2) Оператор INSERT – позволяет включать в таблицу новые записи.INSERT INTO <имя таблицы> [(<список столбцов>)] VALUES (<список значений>) | <подзапрос>Если список столбцов не задан, то значения должны вводиться во все столбцы, если задан, то

вводятся только те значения, которые перечислены в списке, и в том порядке, в котором они перечислены.

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

для символьных – ‘ ’

48

для даты – {}для логических - .Т.для числовых – без разделителя

Пример : INSERT INTO Student VALUES (‘Иванов’, ‘Н334’, 65, .T.,{31.03.85})INSERT INTO Student (FIO, Cr) VALUES (‘Петров’, ‘Н333’)

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

(3) Операция UPDATE – определяет обновление значений заданных столбцов.UPDATE <имя таблицы> SET <имя столбца>=<новое значение> [,<имя столбца>=<новое значение>]

[<предложение WHERE>]Пример : UPDATE Student SET privivka=.T. WHERE Gr=’H333’

(4) Оператор DELETE – используется для удаления строк таблицы.DELETE FROM <имя таблицы> [<предложение WHERE>]Пример : DELETE FROM Student WHERE FIO=’Петров’

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

(5) Оператор выборки SELECT – служит для отбора записей и выдачи результата отбора в заданном виде.SELECT <предложение>FROM < предложение >[INTO < предложение >][WHERE < предложение >][GROUP BY < предложение >] [HAVING < предложение >][UNION <подзапрос>][ORDER BY < предложение >]Ключ: слова SELECT и FROM являются обязательными.

1) Предложение SELECT SELECT [DISTINCT|ALL] [*|<список выражений>]

DISTINCT – выбирается только уникальные строки.ALL – выбираются все строки (по умолчанию)* – в выходную таблицу осуществляется вывод всех столбцов таблицы в том

порядке, в котором они заданы в описании таблицы.<список выражений> – обычно перечисляются те идентификаторы столбцов, которые

выводятся в результирующую таблицу.Пример: таблица ДЕТАЛЬнаим кол-во материал индекс вес номер цена

а) SELECT * FROM ДЕТАЛЬб) SELECT наим, кол-во, материал FROM ДЕТАЛЬ – проекция на три атрибутав) SELECT DISTINCT наим, материал FROM ДЕТАЛЬВ качестве элементов в списке выражений м.б. задано арифметическое выражение для вычисляемого столбца.Пример: SELECT наим, материал, кол-во*цена FROM ДЕТАЛЬ

Для обозначения столбца (задание имени) используется ключевое слово AS после названия столбца.Пример: SELECT наим AS Наименование детали,

материал AS Материал, кол-во*цена AS Стоимость

FROM ДЕТАЛЬ

49

В предложении SELECT могут использоваться стандартные функции: MIN, MAX, SUM, AVG, COUNT. Каждая из этих функций оперирует совокупностью значений в заданном столбце таблицы. Аргументу может предшествовать ключевое слово DISTINCT, указывающее, что дублирующиеся значения не должны включаться в обработку.SELECT COUNT (наим)SELECT COUNT (DISTINCT наим)Пример: SELECT наим ASНаименование детали,

SUM (кол-во*цена) AS Стоимость деталиFROM ДЕТАЛЬWHERE материал = ‘сталь 45’

2) Предложение FROM – может указываться имя одной таблицы или список имен совместно обрабатываемых нескольких таблиц и оператор JOIN (объединение).Пример : SELECT FIO, Gr, Spec FROM Student, GroupОператор JOIN определяет условие объединения таблиц.<имя таблица 1> [INNER|LEFT|RIGHT|FULL] JOIN<имя таблица 2> ON <имя столбца таблица 1> = <имя столбца таблица 2>JOIN определяет имена тех столбцов, по которым осуществляется связь между таблицами. Четыре значения JOIN определяют соответствующую выборку записей в результирующую таблицу.INNER JOIN – создает объединение, в которое выбираются только те записи, которые содержат совпадающие значения в полях связи.LEFT JOIN – создает объединение, в которое выбираются все записи из левой таблицы, а также записи из правой таблицы, значения поля связи которого совпадают со значением поля связи левой таблицы.RIGHT JOIN - объединение, в которое помещаются все записи из правой таблицы и записи из левой таблицы, с совпадающими значениями полей связи.FULL JOIN – полное объединение левой и правой таблиц.SELECT FIO, Gr, Spec FROM Group LEFT JOIN Student ON Group.num – Student.gr_num

3) Предложение WHERE определяет условия отбора записей. Условие отбора м.б. сложным и включать операторы AND и OR.WHERE < условие поиска> AND|OR <условие поиска2>В предложении WHERE может использоваться предикат IN (находится в принадлежности)WHERE [NOT] <выражение> [NOT] IN (<список значений>|<подзапрос>)Пример:WHERE материал NOT IN (‘сталь45’, ‘чугун’)

Диапазон значенийWHERE [NOT] <выражение> [NOT] BETWEEN <нижнее значение> AND <верхнее значение>В условии можно задавать символьное значение для поиска по неточному совпадению.WHERE [NOT] <имя столбца> [NOT] LIKE ‘<поисковая строка>’Пример: WHERE Наименование LIKE ‘Втулка%’ (результат: Втулка1, Втулка2, ..)

Вложенные запросы.Запросы м.б. многоуровневыми, т.е. один SELECT м.б. вложен в другой SELECT. При реализации

вложенного запроса обработка начинается с SELECT’а самого нижнего уровня, и так последовательно поднимается до самого верхнего уровня. Если подзапрос выдает множество значений, то в запросе возможно использование предиката IN, который предназначен для выяснения принадлежности элемента заданному множеству.Пример:

код_пост. код_материала дата кол-во код_материала наим_материала

Поставка Материалы

50

1) Необходима информация о поставке материала ‘железо’SELECT * FROM ПоставкаWHERE код_материала =

(SELECT код_материала FROM МатериалWHERE наим_материала = ‘железо’)

2) Запрос на выдачу наименований материалов, которые поставляются поставщиком Пост_81SELECT наим_материала FROM Материал WHERE код_материала IN

(SELECT код_материала FROM ПоставкаWHERE код_поставщика = ‘Пост_81’)

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

Те же примеры:1) SELECT код_материала, код_поставщика, кол-во FROM Материал

JOIN Поставка ON Материал.код_материала = Поставка.код_материалаWHERE наим_материала = ‘железо’

2) SELECT наим_материала FROM МатериалJOIN Поставка ON Материал.код_материала = Поставка.код_материалаWHERE код_поставщика = ‘Пост_81’

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

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

При использовании подзапросов в предложении WHERE м.б. применен квантор существования EXISTS. Формат WHERE в этом случае имеет вид: WHERE [NOT] EXISTS (<подзапрос>)

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

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

1) ключевому слову EXISTS в предложении WHERE не предшествует имя столбца, константа или какое-либо другое выражение.

2) список выбора подзапроса содержит только символ (*), т.к. нет никакого смысла вводить имена столбцов, поскольку выполняется лишь тест на существование кортежа, который определен в предложении WHERE подзапроса.

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

Пример: SELECT наим_материала FROM Материал WHERE EXISTS

(SELECT * FROM Поставка WHERE код_поставщика = ‘Пост_81’ AND Материал.код_материала = Поставка.код_материала)

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

Пример 2: Необходимо найти материалы, которые еще не поставлялись.1) определим коды материалов, которые поставлялись:

SELECT DISTINCT Материал FROM Поставка JOIN Материал ON Материал.код_материала = Поставка.код_материала

2) с верхним SELECT’ом: (не поставлялись)SELECT наим_материала FROM Материал WHERE NOT EXISTS

51

(SELECT * FROM Поставка WHERE Материал.код_материала = Поставка.код_материала)

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

GROUP BY используется со стандартными функциями. Сама конструкция GROUP BY работает только на одном уровне. Нельзя создать подгруппы в группах и использовать для подгрупп GROUP BY.

Пример: Необходимо внести средние зарплаты по участкамЗарплатаФИО таб_ном участок з/п

SELECT Участ, AVG(з/п) FROM Зарпалата GROUP BY Участок (GROUP BY Группа, Дисциплина)

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

Вместе с GROUP BY может использоваться фраза HAVING. Фраза HAVING означает для группы то же самое, что и фраза WHERE для записи. Т.е. HAVING определяет условие отбора групп.

Пример: необходим список материалов имеющих более одной поставки.SELECT Материал FROM Поставка_материала GROUP BY Материал HAVING Count (*) > 1

Упорядочение данных.Для упорядочения данных используется фраза ORDER BYORDER BY <имя столбца>|<целое> [ASC|DESC]

[,<имя столбца|целое>[ASC|DESC]]Т.о. вместо имени столбца в ORDER BYможет записываться целое число, которое соответствует

номеру столбца в таблице (считая от 1 слева направо). Когда столбцы вычисляемые или являются результатом объединения UNION, то целое должно использоваться вместо имени столбца.

ASC (по умолчанию) - возрастание, DESC – убывание Если в предложении ORDER BY специфицируется несколько имен, то это означает упорядочение по

составному индексу.Пример : SELECT * FROM Student ORDER BY FIO

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

результате выполнения операции SELECT, т.е. можно объединять в одно множество результаты нескольких SELECT’ов.<команда SELECT> UNION <команда SELECT> [UNION <команда SELECT>]Пример: Student Prepod

Список всех студентов и преподавателей:SELECT FIO FROM Student UNION SELECT FIO FROM Prepod

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

При использовании ORDER BY при объединении столбцы должны специфицироваться целыми числами. При этом опция ORDER BY включается в последний SELECT. Следует иметь в виду, что при объединении дубликаты в результирующей таблице всегда исключаются. Оператор UNION может объединять любое число предложений SELECT.

GROUP BY и HAVING при объединении. Т.к. эти операции работают в процессе создания множества окончательных результатов, то они могут быть включены в любой SELECT.

52

Пример: Товар Заказкод цена упаковка код_покуп код_товара дата кол-во

Необходимо выбрать товары, которые имеют стоимость больше 1000р и покупаются клиентом с кодом 023.SELECT код FROM Товар WHERE цена>1000 UNIONSELECT код_товра FROM Заказ WHERE код_покуп = 023

Создание представлений.В SQL различают несколько видов таблиц:1) базовая таблица2) временная таблица3) таблица представленийБазовая таблица создается с помощью CREATE TABLE, временная с помощью CREATE CURCOR,

представления – CREATE VIEW/Временная таблица CURSOR создается в оперативной памяти, CREATE VIEW определяется как

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

CREATE VIEW <имя представления> [<список столбцов выборки>]AS <предложение SELECT>[WITH CHECK OPTION]Пример: В отделе сотрудники закреплены за группами материалов. Предположим, что коды

материалов “металлы” начинаются с буквы М. Это позволяет определить представление, в которое мы включим только те записи, которые начинаются с буквы М.

CREATE VIEW Металлы AS SELECT * FROM Поставка WHERE код_материала LIKE ‘М%’

Представления хранятся в памяти не в виде таблиц. В системном каталоге после создания VIEW хранится его описание с SQL-запросом (VIEW также называется отложенным запросом). При обращении к VIEW SQL-запрос объединяется с SQL-запросом представления и выполняется

1) явное описание столбцов необходимо использовать если возникает потребность в переименовании столбцов.

2) если в SELECT’е имеют место вычисляемые столбцы.3) если в SELECT’е встречается GROUP BY.

При определении VIEW можно указывать любую правильную команду SELECT, кроме:1) нельзя включать UNION2) INTO .. ORDER BY3) нельзя составлять представление для временных таблиц, т.к. возможно, что на момент

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

Подфраза ‘WITH CHECK OPTIONS’ указывает на то, что при корректировке представления должна производиться проверка заданного условия предложения WHERE.

Не все представления м.б. обновляемыми. Представление не м.б. обновляемым, если:1) содержит ключевое слово DISTINCT2) содержит агрегатные функции3) предложения GROUP BY и HAVING

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

VIEW МеталлSELECT * FROM Металлы WHERE наим_материала = ‘бронза’

53

Операторы GRANT и REVOKE . Эти операторы определяют привилегию доступа к данным и изымают привилегию (REVOKE). Возможен на уровне SELECT (выборки), INSERT (добавление), UPDATE (модификация), DELETE (удаление). Причем привилегия может определяться как для таблиц, так и для столбцов.Пример : GRANT INSERT, DELETE ON Покупка To Ivanov

GRANT INSERT, DELETE ON Покупка From Petrov GRANT INSERT, SELECT ON Покупка (код_покупки) To Sidorov

Технология и модели клиент-сервер.Клиент-сервер – это модель взаимодействия компьютеров в сети. Как правило, компьютеры не

являются равноправными. Одни компьютеры владеют и распоряжаются какими-либо ресурсами, другие компьютеры обращаются к этим ресурсам (самое простое – вычислительные ресурсы и память).

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

1) Функции ввода и отображения данных2) Прикладные функции, которые реализуют бизнес-логику3) Функции хранения и доступа к данным4) Функции связи между выделенными функциональными компонентами.

В соответствии с таким делением на функциональные группы в приложении различают:1) компонент представления, который реализует функции 1ой группы2) прикладной компонент, предназначенный для реализации бизнес - логики3) компонент доступа к данным, который поддерживает функции 3й группы.

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

Различия в реализации технологии клиент-сервер определяются четырьмя факторами:1) тем, в какие виды программного обеспечения интегрированы каждый из компонентов.2) тем, какие механизмы используются для реализации выделенных функций3) как логические компоненты распределяются между компонентами в сети4) какие механизмы используются для связи компонент между собой.

В соответствии с этим существуют 4 типа моделей клиент-сервер:1. FileServer – FS2. Remote Data Access – RDA3. DataBase Server – DBS4. Application Server – AS

1) Файл-сервер ( FS ) Минусы: 1. Высокий сетевой трафик, т.к. передаются

все файлы (целиком)2. Операции только над файлами (узкий спектр)3. Защита только на уровне файла.

2) Удаленный доступ к данным ( RDA ) Плюсы:1. Снижение трафика – т.к. по сети передаются

SQL-запросы, а не файлы данных.2. Разгрузили сервер от несвойственных задач.3. Стандартизованный интерфейс связи в виде

языка SQLМинусы:

54

компонент представления

прикладной компонент

компонент доступа к данным

серверклиенткопия СУБД (ядро СУБД)

запрос на файл

файлы

компонент представления

прикладной компонент

компонент доступа к данным

SQL-серверклиент

SQL

данные

1. Трафик все-таки есть, т.к. запросы м.б. достаточно объемными2. Сложности в администрировании прикладного компонента (т.к. он расположен на клиенте, а их

м.б. много).

3) Модель сервера БД ( DBS ).

компонент представления

прикладной компонент

компонент доступа к данным

клиент сервер

SQL

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

Плюсы: 1) уменьшение трафика2) упрощение администрирования прикладного компонента3) возможность настройки обработки SQL-запросов в хранимых процедурах (т.е. оптимизация

обработки).Минусы:

1) хранимая процедура пишется на процедурном расширении SQL, который по средствам отладки значительно уступает языкам высокого уровня.

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

Модель доступа к удаленным данным:Толстый клиент – тонкий сервер

Модель сервера БД:Тонкий клиент – толстый сервер

Модели FS, RDA, DBS – двухзвенные.

4) Сервер приложений ( AS ) Плюсы:

1. Все изменения, которые делаются на каждом из уровней, являются независимыми.

2. Снижется нагрузка на сеть, т.к. звенья не обмениваются между собой большими объемами

данных.3. Обеспечивается масштабируемость и простая модификация оборудования и программного

обеспечения каждого звена.4. Приложения прикладного компонента могут создаваться на стандартных языках 3го и 4го

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

приложений. Обращение к нему осуществляют компоненты представления, а интерфейс между ними – стандартный Application Program Interface. Дальше → через SQL. Т.о. прикладной компонент является сервером по отношению к компьютерному представлению и клиентом по отношению к серверу БД.

Для работы сервера приложений используется универсальные механизмы многозадачности, а сам сервер приложений основывается на т.н. мониторах обработки транзакций (Transaction Processing Monitor). Мониторы транзакций составляют особый вид программного обеспечения, который относят к категории среднего слоя (middle-wave), т.е. посредническому (промежуточному) слою. Они обеспечивают оптимальное управление тем потоком запросов, которые следуют от клиента.

55

компонент представления

клиент

прикладной компонент

компонент доступа к данным

SQLAPI

(верхний уровень) (средний уровень)сервер приложений сервер БД

(нижний уровень)

Плюсы: 1) Серверы приложений облегчают жизнь разработчику, т.к. автоматизируют низкоуровневый

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

1) выполнение бизнес-логики2) обращение к данным3) интеграция приложений

56