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

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

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

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

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

ДАТЬ (МИХАИЛ, ВЛАДИМИРУ, КНИГУ);

($x) (ЭЛЕМЕНТ (x, СОБЫТИЕ-ДАТЬ) ? ИСТОЧНИК (x, МИХАИЛ) ? АДРЕСАТ? (x, ВЛАДИМИР) ОБЪЕКТ(x, КНИГА).

Здесь описаны два способа записи одного факта: «Михаил дал книгу Владимиру».

Логический вывод осуществляется с помощью силлогизма (если из A следует B, а из B следует C, то из A следует C).

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

S = ,

где B - счетное множество базовых символов (алфавит) теории S;

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

A - выделенное множество формул, называемые аксиомами теории S, то есть множество априорных формул;

R - конечное множество отношений {r 1 , …, r n } между формулами, называемые правилами вывода .

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

Покажем метод резолюций.

В методе используется несколько понятий и теорем.

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

Теорема 1. А?В тогда и только тогда, когда?А В.

Теорема 2. А1, А2, ..., Аn ? В тогда и только тогда, когда? (A1?A2?A3?…?An) В.

Символ? читается как «верно, что» или «можно вывести».

В основе метода лежит доказательство тавтологии

? (X ? A) ?(Y ? ? A)?(X ? Y ) .

Теоремы 1 и 2 позволяют записать это правило в следующем виде:

(X ? A), (Y ? ? A) ? (X ? Y ),

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

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

1. Устраняются операции эквивалентности и импликации:

2. Операция отрицания продвигается внутрь формул с помощью законов де Моргана:

3. Логические формулы приводятся к дизъюнктивной форме: .

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

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

1.Приведение посылок к дизъюнктивной форме:
, , .

2.Построение отрицания выводимого заключения . Полученная конъюнкция справедлива, когда и одновременно истинны.

3.Применение правила резолюции:

(противоречие или «пустой дизъюнкт»).

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

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

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

Алгоритм унификации предикатных логических формул включает следующие шаги.

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

Пример: представим средствами логики предикатов следующий текст:

«Если студент умеет хорошо программировать, то он может стать специалистом в области прикладной информатики».

«Если студент хорошо сдал экзамен по информационным системам, значит, он умеет хорошо программировать».

Представим этот текст средствами логики предикатов первого порядка. Введем обозначения: X - переменная для обозначения студента; хорошо - константа, соответствующая уровню квалификации; Р(Х) - предикат, выражающий возможность субъекта X стать специалистом по прикладной информатике; Q (Х, хорошо) - предикат, обозначающий умение субъекта X программировать с оценкой хорошо ; R (Х, хорошо) - предикат, задающий связь студента X с экзаменационной оценкой по информационным системам.

Теперь построим множество правильно построенных формул:

Q(Х, хорошо) .

R (Х, хорошо) Q (Х, хорошо).

Дополним полученную теорию конкретным фактом
R (иванов, хорошо) .

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

Доказательство

1. Выполним преобразование исходных формул теории в целях приведения к дизъюнктивной форме:

(Х, хорошо) Р(Х);

(Х,хорошо) (Х,хорошо);

R (иванов , хорошо).

2. Добавим к имеющимся аксиомам отрицание выводимого заключения

(иванов).

3. Построим конъюнкцию дизъюнктов

(Х, хорошо) Р(Х) ? ? P (иванов, хорошо) ? ? Q (иванов, хорошо), заменяя переменную X на константу иванов .

Результат применения правила резолюции называют резольвентой . В данном случае резольвентой является (иванов).

4. Построим конъюнкцию дизъюнктов с использованием резольвенты, полученной на шаге 3:

(Х, хорошо) (Х, хорошо) (иванов, хорошо) (иванов, хорошо).

5. Запишем конъюнкцию полученной резольвенты с последним дизъюнктом теории:

(иванов, хорошо) (иванов, хорошо) (противоречие).

Следовательно, факт Р(иванов ) выводим из аксиом данной теории.

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

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

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

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

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

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

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

Иерархическая;

Сетевая;

Реляционная.

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

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

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

Описание пользователей и групп пользователей системы

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

Модель предметной области

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

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

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

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

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

Модель «сущность-связь» представлена в Приложении Е.

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

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

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

Bilety - информация реализованных билетах;

Films - информация о всех имеющихся в кинотеатре фильмах;

Seansy - информация о времени проведения сеансов и стоимости билетов на эти сеансы;

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

Понятия БД и СУБД.

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

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

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

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

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

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

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

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

Выделяют следующие виды СУБД:

* полнофункциональные СУБД;

* серверы БД;

* средства разработки программ работы с БД.

По характеру использования СУБД делят на многопользователь­ские (промышленные) и локальные (персональные).

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

* возможность организации совместной параллельной работы мно­гих пользователей;

* масштабируемость;

* переносимость на различные аппаратные и программные платформы;

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

* обеспечение безопасности хранимых данных и развитой струк­турированной системы доступа к ним.

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

* относительная простота эксплуатации, позволяющая создавать на их основе работоспособные пользовательские приложения;

* относительно ограниченные требования к аппаратным ресурсам.

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

Для работы с данными, хранящимися в базе, используются следу­ющие типы языков:

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

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

Названные языки в различных СУБД могут иметь отличия. Наи­большее распространение получили два стандартизованных языка: QBE - язык запросов по образцу и SQL - структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов.

СУБД реализует следующие основные функции низкого уровня:

* управление данными во внешней памяти;

* управление буферами оперативной памяти;

* управление транзакциями;

* ведение журнала изменений в БД;

* обеспечение целостности и безопасности БД.

Реализация функции управления данными во внешней памяти обес­печивает организацию управления ресурсами в файловой системе ОС.

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

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

Транзакции присущи три основных свойства:

* атомарность (выполняются все входящие в транзакцию операции или ни одна);

* сериализуемость (отсутствует взаимное влияние выполняемых в одно и то же время транзакций);

* долговечность (даже крах системы не приводит к утрате резуль­татов зафиксированной транзакции).

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

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

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

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

Этапы создания БД.

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

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

Перечислим этапы концептуального проектирования:

1. Изучение предметной области для формирования общего пред­ставления о ней;

2. Выделение и анализ функций и задач разрабатываемой ИС;

3. Определение основных объектов-сущностей предметной области
и отношений между ними;

4. Формализованное представление предметной области.

При проектировании схемы реляционной БД можно выделить сле­дующие процедуры:

1.Определение перечня таблиц и связей между ними;

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

3.Установление индексирования для полей в таблицах;

4.Разработка списков (словарей) для полей с перечислительными
данными;

5.Установление ограничений целостности для таблиц и связей;

6.Нормализация таблиц, корректировка перечня таблиц и связей.

Реляционные БД.

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

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

Первичный ключ

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

Данные таблицы «Преподаватель»

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

Вторичный ключ

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

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

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

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

- «один-ко-многим»

- «один-к-одному»

- «многие-ко-многим»

Отношение «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.

Отношение «многие-ко-многим» имеет место, когда:

а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;

б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.

Отношение «один-ко-многим» имеет место, когда одной записи родительской таблицы может соответствовать несколько записей в дочерней таблице.

Физическая и логическая модели БД

Логическая модель данных . На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

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

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

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

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

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

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

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

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

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

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

ERD-диаграммы

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

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

Рис. 6.1. Пример ERD-диаграммы,

Определение сущностей и атрибутов

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

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

Рис. 6.2. ERD- диаграмма с атрибутами

Логические взаимосвязи

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

Некоторые примеры взаимосвязей:

• команда включает много игроков,
• самолет перевозит много пассажиров,
• продавец продает много продуктов.

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

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

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

Проверка адекватности логической модели

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

Самолет перевозит пассажиров. Много пассажиров перевозятся одним самолетом.

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

Рис. 6.3. Пример логической модели со взаимосвязью

Модель данных, основанная на ключах

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

Выбор первичного ключа

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

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

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

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

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

Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERWin генерирует неуникальный индекс для каждого инверсионного входа.

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

Пример

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

Таблица 6.1. Атрибуты сущности «Студент»

Атрибут	Описание
Номер	Уникальный номер для идентификации пользователя
Ф.И.О.	Фамилия, имя и отчество пользователя
Пароль	Пароль для доступа в систему
Возраст	Возраст студента
Пол	Пол студента
Характеристика	Memo-поле с общей характеристикой пользователя
E-mail	Адреса электронной почты
Телефон	Номера телефонов студента (домашний, рабочий)
Опыт работы	Специальности и опыт работы студента по каждой из них
Специальность	Специальность, получаемая студентом при окончании учебного заведения
Специализация	Направление специальности, по которому обучается студент
Иностранный язык	Список иностранных языков и уровень владения ими
Тестирование	Список тестов и отметки о их прохождении
Экспертная оценка	Список предметов с экспертными оценками по каждому из них
Оценки по экзаменам	Список сданных предметов с оценками

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

Таблица 6.2. Атрибуты сущности «Опыт работы»

Таблица 6.3. Атрибуты сущности «Иностранный язык»

Таблица 6.4. Атрибуты сущности «Тестирование»

Таблица 6.5. Атрибуты сущности «Экспертная оценка»

Атрибут	Описание
Дисциплина	Наименование дисциплины, по которой оценивался студент
Ф.И.О. преподавателя	Ф.И.О. преподавателя, который оценивал студента
Оценка	Экспертная оценку преподавателя
Атрибут		Описание
Предмет		Название предмета, экзамен по которому сдавался
Оценка		Полученная оценка

Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи между сущностями (рис. 6.4). Все сущности будут зависимыми от сущности «Студент». Связи будут типа «один-ко-многим».

Рис. 6.4. ERD-диаграмма БД студентов

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

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

Таблица 6.7. Типы атрибутов

Атрибут	Тип
Характеристика
Специальность
Специализация
Место работы
Уровень владения
Название
Описание
Дисциплина
Ф.И.О. преподавателя

Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Студент» это будет уникальный номер, для сущности «Опыт работы» все поля являются ключевыми, так как по разным специальностям студент может иметь разный опыт работы в разных фирмах. Сущность «Тест» определяется названием, так как студент по одному тесту может иметь только одну оценку. Оценка по экзамену определяется только названием предмета, экспертная оценка зависит от преподавателя, который ее составил, поэтому в качестве ключевых атрибутов выберем «Дисциплину» и «Ф.И.О. преподавателя». У сущности «Иностранный язык» уровень владения зависит только от наименования языка, следовательно, это и будет являться ключевым атрибутом.

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

Рис. 6.5. ERD-диаграмма БД студентов с ключевыми атрибутами

Контрольные вопросы

1. Назовите основные части ERD-диаграммы.
2. Цель ERD-диаграммы.
3. Что является основным компонентом реляционных БД?
4. Что называется сущностью?
5. Сформулируйте принцип именования сущностей.
6. Что показывает взаимосвязь между сущностями?
7. Назовите типы логических взаимосвязей.
8. Каким образом отображаются логические взаимосвязи?
9. Опишите механизм проверки адекватности логической модели.
10. Что называется первичным ключом?
11. Назовите принципы, согласно которым формируется первичный ключ.
12. Что называется альтернативным ключом?
13. Что называется инверсионным входом?
14. В каком случае образуются внешние ключи?

1. Тема, цель работы.
2. ERD-диаграмма БД Служба занятости с атрибутами и ключами.
3. Выводы по работе

Введение. Основные понятия баз данных

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

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

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

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

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

Примерами серверов могут служить:

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

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

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

Файловый сервер, поддерживающий общее хранение файлов для всех рабочих станций;

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

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

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

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

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

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

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

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

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

· обработка данных - данные можно обрабатывать различными способами: выбирать любые поля, фильтровать и сортировать данные, объединять данные и вычислять итоговые значения;

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

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

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

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

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

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

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

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

Типичным представителем (наиболее известным и распространенным) является СУБД IMS (Information Management System) компании IBM. Первая версия системы появилась в 1968 г.

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

Под сетевой моделью понимается модель данных, подобная иерархической, но допускающая свободную систему связей между узлами различных уровней. Она является расширением иерархической модели данных. Таким образом, сетевые модели допускают наличие двух и более «предков» (рис.2).

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

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

Рис. 2. Сетевая модель данных

Типичным представителем систем, основанных на сетевой модели данных, является СУБД IDMS (Integrated Database Management System), разработанная компанией Cullinet Software, Inc. и изначально ориентированная на использование мэйнфреймов (ЭВМ общего назначения) компании IBM. Архитектура системы основана на предложениях Data Base Task Group (DBTG) организации CODASYL (Conference on Data Systems Languages), которая отвечала за определение языка программирования COBOL. Отчет DBTG был опубликован в 1971 г., и вскоре после этого появилось несколько систем, поддерживающих архитектуру CODASYL, среди которых присутствовала и СУБД IDMS. В настоящее время IDMS принадлежит компании Computer Associates.

Нормализация базы данных

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

Рассмотрим пример нормализации БД управления доставкой заказов. Неупорядоченная БД «Продажи» состояла бы из одной таблицы (рис.7).

Рис.7. БД «Продажи»

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

Первая нормальная форма

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

Выполним нормализацию БД " Продажи" до первой нормальной формы (рис.8).

Рис.8. Первая нормальная форма

3.3.2. Вторая нормальная форма

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

Выполним нормализацию БД " Продажи" до второй нормальной формы. Все сведения, не связанные с отдельными заказами, выделим в отдельную таблицу. В итоге получим вместо одной таблицы " Продажи" получим две - таблицу "Заказы" (рис.9) и таблицу "Товары" (рис.10).

Рис.9. Таблица "Заказы"

Рис.10. Таблица "Товары"

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

3.3.3. Третья нормальная форма

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

Выполним нормализацию БД "Продажи" до третьей нормальной формы. Для этого следует удалить из таблицы "Заказы" столбец "Всего". Значения в этом столбце не зависят ни от одного ключа и могут быть вычислены по формуле ("Цена")*("Количество"). Таким образом, получена БД "Продажи" с оптимальной структурой, которая состоит из двух таблиц (рис.11).

Рис. 11. Нормализованная БД "Продажи"

3.2 Программная реализация базы данных

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

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

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

3.2.1. Разработка приложений

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

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

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

3.2.2 Тестирование базы данных

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

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

3.3 Эксплуатация и сопровождение базы данных

Эксплуатация и сопровождение - поддержка нормального функционирования БД.

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

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

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

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

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

4. СУБД Microsoft Access

4.1.Назначение и общие сведения о СУБД Microsoft Access

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

К областям применения Microsoft Access можно отнести следующие:

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

· в крупных корпорациях (приложения для рабочих групп, системы обработки информации);

· в качестве персональной СУБД (справочник по адресам, ведение инвестиционного портфеля, поваренная книга, каталоги книг, пластинок, видеофильмов и т. п.).

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

Средствами разработки объектов в Access являются «мастера» и «конструкторы». Это специальные программы, которые служат для создания и редактирования таблиц, запросов, различных типов форм и отчетов. Как правило «мастер» используется для создания, а «конструктор» - для редактирования объектов. Процесс редактирования предполагает изменение вида некоторого объекта с целью его улучшения. При редактировании формы можно изменить названия и порядок расположения полей, увеличить или уменьшить размер области ввода данных, и т.д. Можно использовать «конструктор» и для создания форм, но это очень трудоемкая работа. В Access включены специальные программные средства, помогающие производить анализ структуры данных, импортировать электронные таблицы и текстовые данные, повышать быстродействие приложений, создавать и настраивать приложения с использованием встроенных шаблонов. Чтобы полностью автоматизировать работу приложений, можно использовать макросы для связывания данных с формами и отчетами.

В Access реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи. Обеспечивает целостность данных на уровне ядра, что не разрешает несовместимые операции обновления или удаления данных. Таблицы в Access снабжены средствами проверки допустимости данных, т.е. не разрешается некорректный ввод. Каждое поле таблицы имеет свой формат и стандартные описания, что облегчает ввод данных. Access поддерживает следующие типы полей, в том числе: вкладка, текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка, поля объектов OLE, вложение и вычисляемый. Если в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений.

В Access можно использовать графические средства, как и в Microsoft Word, Excel, PowerPoint и других приложениях, позволяющие создавать различные виды графиков и диаграмм. Можно создавать гистограммы, двухмерные и трехмерные диаграммы. В формы и отчеты Access можно добавлять всевозможные объекты: рисунки, диаграммы, аудио- и видеоклипы. Связывая эти объекты с разработанной базой данных, можно создавать динамические формы и отчеты. Также в Access можно использовать макросы, позволяющие автоматизировать выполнение некоторых задач. Они позволяют открывать и закрывать формы и отчеты, создавать меню и диалоговые окна с целью автоматизации создания различных прикладных задач.

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

4.2. Объекты Microsoft Access

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

Рис. 12. Запуск Access

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

При создании новой базы данных Access откроет пустую таблицу, содержащую одну строку и два столбца (рис 13).

Рис.13. Окно новой базы данных

В левой части окна (область переходов) показаны все созданные объекты БД, пока мы лишь видим, пустую таблицу, т.к. созданных объектов в новой базе данных больше нет (рис. 13). К основным объектам СУБД Access относятся следующие.

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

Таблицы в Access могут быть созданы следующим образом:

· в режиме «конструктора»;

· в режиме ввода данных в таблицу.

Создать таблицу можно путем импорта данных, хранящихся в другом месте, или создания связи с ними. Это можно сделать, например, с данными, хранящимися в файле Excel, в списке Windows SharePoint Services, XML-файле, другой базе данных MS ACCESS. Список SharePoint позволяет предоставить доступ к данным пользователям, у которых не установлено приложение MS ACCESS. При импорте данных создается их копия в новой таблице текущей базы данных. Последующие изменения, вносимые в исходные данные, не будут влиять на импортированные данные, и наоборот. Если осуществляется связывание с данными, в текущей базе данных создается связанная таблица, обеспечивающая динамическое подключение к данным, хранящимся в другом месте. Изменения данных в связанной таблице отражаются в источнике, а изменения в источнике - в связанной таблице.

В режиме таблицы отображаются данные, которые хранятся в таблице, а в режиме «конструктора» отображается структура таблицы.

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

Запросы . Запросы - это специальные средства, предназначенные для поиска и анализа информации в таблицах базы данных, отвечающей определенным критериям. Найденные записи, называемые результатами запроса, можно просматривать, редактировать и анализировать различными способами. Кроме того, результаты запроса могут использоваться в качестве основы для создания других объектов Access. Существуют различные типы запросов, наиболее распространенными из которых являются запросы на выборку, параметрические и перекрестные запросы, запросы на удаление записи, изменение и другие. Реже используются запросы на действие и запросы SQL (Structured Query Language). Если нужного запроса нет, то его можно создать дополнительно.

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

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

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

· «форма»;

· «разделенная форма»;

· «несколько элементов»;

· «пустая форма».

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

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

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

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

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

Страницы. Чтобы предоставить пользователям Интернета доступ к информации, в базе данных можно создать специальные страницы доступа к данным. С помощью страниц доступа к данным можно просматривать, добавлять, изменять и обрабатывать данные, хранящиеся в базе данных. Страницы доступа к данным могут также содержать данные из других источников, например, из Excel. Для публикации информации из базы данных в Web Access включают «мастер», который обеспечивает создание страницы доступа.

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

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

Создание таблиц

При вводе данных в Access полям присваиваются имена: Поле1, Поле2 и так далее. Можно использовать предложенные имена или изменить их. Название полей в таблице можно задавать двумя способами. После выбора способа создания таблицы выполняется команда «Создать »и вызывается соответствующее окно. На рис.8. показано создание таблицы в режиме «конструктора». Создаются требуемые поля таблицы с заданным типом данных, который выбирается посредством кнопки выбора – «галочка», в нижней части окна находится раздел выбора свойств поля, которые предлагаются вначале по умолчанию.

Рис. 14. Создание таблицы в режиме конструктора

Свойства полей таблицы базы данных Access указаны в нижней половине таблицы (рис.14).

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

При создании таблиц используются следующие основные типы данных (рис.15).