Понятия БД и СУБД.
База данных представляет собой совокупность структурированных данных, хранимых в памяти вычислительной системы и отображающих состояние объектов и их взаимосвязей в рассматриваемой предметной области.
Логическую структуру данных, хранимых в базе, называют моделью представления данных. К основным моделям представления данных (моделям данных) относятся иерархическая, сетевая, реляционная.
Система управления базами данных (СУБД) - это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по используемой модели данных. Так, СУБД, основанные на использовании реляционной модели данных, называют реляционными СУБД.
Словарь данных представляет собой подсистему БД, предназначенную для централизованного хранения информации о структурах данных, взаимосвязях файлов БД друг с другом, типах данных и форматах их представления, принадлежности данных пользователям, кодах защиты и разграничения доступа и т. п.
Информационные системы, основанные на использовании БД, обычно функционируют в архитектуре клиент-сервер. В этом случае БД размещается на компьютере-сервере, и к ней осуществляется совместный доступ.
Сервером определенного ресурса в компьютерной сети называется компьютер (программа), управляющий этим ресурсом, клиентом - компьютер (программа), использующий этот ресурс. В качестве ресурса компьютерной сети могут выступать, к примеру, базы данных, файлы, службы печати, почтовые службы.
Достоинством организации информационной системы на архитектуре клиент-сервер является удачное сочетание централизованного хранения, обслуживания и коллективного доступа к общей корпоративной информации с индивидуальной работой пользователей.
Согласно основному принципу архитектуры клиент-сервер, данные обрабатываются только на сервере. Пользователь или приложение формируют запросы, которые поступают к серверу БД в виде инструкций языка SQL. Сервер базы данных обеспечивает поиск и извлечение нужных данных, которые затем передаются на компьютер пользователя. Достоинством такого подхода в сравнении предыдущим является заметно меньший объем передаваемых данных.
Выделяют следующие виды СУБД:
* полнофункциональные СУБД;
* серверы БД;
* средства разработки программ работы с БД.
По характеру использования СУБД делят на многопользовательские (промышленные) и локальные (персональные).
Промышленные, СУБД представляют собой программную основу для разработки автоматизированных систем управления крупными экономическими объектами. Промышленные СУБД должны удовлетворять следующим требованиям:
* возможность организации совместной параллельной работы многих пользователей;
* масштабируемость;
* переносимость на различные аппаратные и программные платформы;
* устойчивость по отношению к сбоям различного рода, в том числе наличие многоуровневой системы резервирования хранимой информации;
* обеспечение безопасности хранимых данных и развитой структурированной системы доступа к ним.
Персональные СУБД - это программное обеспечение, ориентированное на решение задач локального пользователя или небольшой группы пользователей и предназначенное для использования на персональном компьютере. Это объясняет и их второе название - настольные. Определяющими характеристиками настольных систем являются:
* относительная простота эксплуатации, позволяющая создавать на их основе работоспособные пользовательские приложения;
* относительно ограниченные требования к аппаратным ресурсам.
По используемой модели данных СУБД разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и др. Некоторые СУБД могут одновременно поддерживать несколько моделей данных.
Для работы с данными, хранящимися в базе, используются следующие типы языков:
* язык описания данных - высокоуровневый непроцедурный язык
декларативного типа, предназначенный для описания логической
структуры данных;
* язык манипулирования данными - совокупность конструкций, обеспечивающих выполнение основных операций по работе с данными: ввод, модификацию и выборку данных по запросам.
Названные языки в различных СУБД могут иметь отличия. Наибольшее распространение получили два стандартизованных языка: QBE - язык запросов по образцу и SQL - структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов.
СУБД реализует следующие основные функции низкого уровня:
* управление данными во внешней памяти;
* управление буферами оперативной памяти;
* управление транзакциями;
* ведение журнала изменений в БД;
* обеспечение целостности и безопасности БД.
Реализация функции управления данными во внешней памяти обеспечивает организацию управления ресурсами в файловой системе ОС.
Необходимость буферизации данных обусловлена тем, что объем оперативной памяти меньше объема внешней памяти. Буферы представляют собой области оперативной памяти, предназначенные для ускорения обмена между внешней и оперативной памятью. В буферах временно хранятся фрагменты БД, данные из которых предполагается использовать при обращении к СУБД или планируется записать в базу после обработки.
Механизм транзакций используется в СУБД для поддержания целостности данных в базе. Транзакцией называется некоторая неделимая последовательность операций над данными БД, которая отслеживается СУБД от начала и до завершения. Если по каким-либо причинам (сбои и отказы оборудования, ошибки в программном обеспечении, включая приложение) транзакция остается незавершенной, то она отменяется.
Транзакции присущи три основных свойства:
* атомарность (выполняются все входящие в транзакцию операции или ни одна);
* сериализуемость (отсутствует взаимное влияние выполняемых в одно и то же время транзакций);
* долговечность (даже крах системы не приводит к утрате результатов зафиксированной транзакции).
Примером транзакции является операция перевода денег с одного счета на другой в банковской системе. Сначала снимают деньги с одного счета, затем начисляют их на другой счет. Если хотя бы одно из действий не выполнится успешно, результат операции окажется неверным и будет нарушен баланс операции.
Ведение журнала изменений выполняется СУБД для обеспечения надежности хранения данных в базе при наличии аппаратных и программных сбоев.
Обеспечение целостности БД составляет необходимое условие успешного функционирования БД, особенно при ее сетевом использовании. Целостность БД - это свойство базы данных, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные.
Обеспечение безопасности достигается в СУБД шифрованием данных, парольной защитой, поддержкой уровней доступа к базе данных и отдельным ее элементам (таблицам, формам, отчетам и др.).
Этапы создания БД.
Проектирование баз данных информационных систем является достаточно трудоемкой задачей. Оно осуществляется на основе формализации структуры и процессов предметной области, сведения о которой предполагается хранить в БД. Различают концептуальное и схемно-структурное проектирование.
Концептуальное проектирование БД ИС является в значительной степени эвристическим процессом. Адекватность построенной в его рамках инфологической модели предметной области проверяется опытным путем, в процессе функционирования ИС.
Перечислим этапы концептуального проектирования:
1. Изучение предметной области для формирования общего представления о ней;
2. Выделение и анализ функций и задач разрабатываемой ИС;
3. Определение основных объектов-сущностей предметной области
и отношений между ними;
4. Формализованное представление предметной области.
При проектировании схемы реляционной БД можно выделить следующие процедуры:
1.Определение перечня таблиц и связей между ними;
2.Определение перечня полей, типов полей, ключевых полей каждой таблицы (схемы таблицы), установление связей между таблицами через внешние ключи;
3.Установление индексирования для полей в таблицах;
4.Разработка списков (словарей) для полей с перечислительными
данными;
5.Установление ограничений целостности для таблиц и связей;
6.Нормализация таблиц, корректировка перечня таблиц и связей.
Реляционные БД.
Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного вида. Каждая строка таблицы содержит данные об одном объекте (например, автомобиле, компьютере, клиенте), а столбцы таблицы содержат различные характеристики этих объектов - атрибуты (например, номер двигателя, марка процессора, телефоны фирм или клиентов).
Строки таблицы называются записями. Все записи таблицы имеют одинаковую структуру - они состоят из полей (элементов данных), в которых хранятся атрибуты объекта (рис. 1). Каждое поле записи содержит одну характеристику объекта и представляет собой заданный тип данных (например, текстовая строка, число, дата). Для идентификации записей используется первичный ключ. Первичным ключом называется набор полей таблицы, комбинация значений которых однозначно определяет каждую запись в таблице.
Первичный ключ
В каждой таблице БД может существовать первичный ключ. Под первичным ключом понимают поле или набор полей, однозначно (уникально) идентифицирующих запись. Первичный ключ должен быть минимально достаточным: в нем не должно быть полей, удаление которых из первичного ключа не отразится на его уникальности.
Данные таблицы «Преподаватель»
В качестве первичного ключа в таблице «Преподаватель» может выступать только «Таб. №», значения других полей могут повторяться внутри данной таблицы.
Вторичный ключ
Вторичные ключи - это основной механизм для организации связей между таблицами и поддержания целостности и непротиворечивости информации в базе данных.
Вторичный – это поле таблицы, которое может содержать только те значения, которые находятся в ключевом поле другой таблицы, на которую ссылается вторичный ключ. Вторичный ключ связывает две таблицы.
Между двумя или более таблицами базы данных могут существовать отношения подчиненности. Отношения подчиненности определяют, что для каждой записи главной таблицы {master,называемой еще родительской} может существовать одна или несколько записей в подчиненной таблице {detail, называемой еще дочерней}.
Существует три разновидности связей между таблицами базы данных:
- «один-ко-многим»
- «один-к-одному»
- «многие-ко-многим»
Отношение «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.
Отношение «многие-ко-многим» имеет место, когда:
а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;
б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице.
Отношение «один-ко-многим» имеет место, когда одной записи родительской таблицы может соответствовать несколько записей в дочерней таблице.
Физическая и логическая модели БД
Логическая модель данных . На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".
Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД . Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship , диаграммы сущность-связь ). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, т.к. мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.
Решения, принятые на предыдущем уровне, при разработке модели предметной области, определяют некоторые границы, в пределах которых можно развивать логическую модель данных, в пределах же этих границ можно принимать различные решения. Например, модель предметной области складского учета содержит понятия "склад", "накладная", "товар". При разработке соответствующей реляционной модели эти термины обязательно должны быть использованы, но различных способов реализации тут много - можно создать одно отношение, в котором будут присутствовать в качестве атрибутов "склад", "накладная", "товар", а можно создать три отдельных отношения, по одному на каждое понятие.
При разработке логической модели данных возникают вопросы: хорошо ли спроектированы отношения? Правильно ли они отражают модель предметной области, а следовательно и саму предметную область?
Физическая модель данных . На еще более низком уровне находится физическая модель данных. Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур. При этом опять-таки решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных. Точно также, в пределах этих границ можно принимать различные решения. Например, отношения, содержащиеся в логической модели данных, должны быть преобразованы в таблицы, но для каждой таблицы можно дополнительно объявить различные индексы, повышающие скорость обращения к данным. Многое тут зависит от конкретной СУБД.
При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы? Насколько много программного кода в виде триггеров и хранимых процедур необходимо разработать для поддержания целостности данных?
Логическая модель данных - описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы.
Логическая модель строится в несколько этапов с постепенным приближением к оптимальному для данных условий варианту. Эффективность такой модели зависит от того, насколько близко она отображает изучаемую предметную область. К предметной области относятся объекты (документы, счета, операции над ними и пр.), а также характеристики данных объектов, их свойства, взаимодействие и взаимное влияние.
Таким образом, при построении логической модели данных сначала выявляются те объекты, которые интересуют пользователей проектируемой базы данных. Затем для каждого объекта формулируются характеристики и свойства, достаточно полно описывающие данный объект. Эти характеристики в дальнейшем будут отражены в базе данных как соответствующие поля.
Логическая модель данных строится в рамках одного из трех подходов к созданию баз данных. Выделяют следующие виды логических моделей базы данных:
Иерархическая;
Сетевая;
Реляционная.
Иерархическая модель представляет собой древовидную структуру, которая выражает связи подчинения нижнего уровня высшему. Это облегчает поиск информации в том случае, если запросы имеют такую же структуру.
Сетевая модель отличается от предыдущей наличием также и горизонтальных связей. Это усложняет как модель, так и саму базу данных и средства ее управления.
Реляционная модель представляет хранимую информацию в виде таблиц, над которыми возможно выполнение логических операций (операций реляционной алгебры). В настоящий момент этот вид моделей получил наибольшее распространение. Это связано со сравнительной простотой реализации, четкой определенностью отношений между объектами, простотой изменения структуры базы данных.
Описание пользователей и групп пользователей системы
Разрабатываемая информационно-справочная система может быть использована как сотрудниками кинотеатра, так и посетителями. Сотрудник кинотеатра может обеспечивать редактирование имеющейся информации об имеющихся фильмах, изменять график работы кинотеатра, включать вновь поступившие фильмы в репертуар кинотеатра; а посетитель может просматривать информацию о графике работы кинотеатра, стоимости билетов, фильмах на сегодня.
Модель предметной области
Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель "сущность-связь" (entity - relationship model, ER - model). Модель "сущность-связь" основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Категории «сущность» и «связь» объявляются основополагающими, и разделение их производится на этапе создания конкретных представлений некоторой предметной области.
Каждая сущность принадлежит к некоторому классу, иначе говоря, ей соответствует некоторый тип. Между сущностями имеются связи, которые пользователь относит к определенному классу (типу). Таким образом, класс сущностей и класс связей определяют множества конкретных объектов и связей между ними. Некоторая сущность может принадлежать более чем к одному классу.
Совокупность сущностей и классов связей образует верхний уровень модели.
Сущности и связи описываются характерными для них атрибутами. Среди атрибутов какой-нибудь сущности или связи выделяется подсписок, значения атрибутов которого однозначно идентифицируют сущность или связь в пределах типа. Сущности, связи и атрибуты образуют нижний уровень модели.
Важным является тот факт, что из модели "сущность-связь" могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.
Модель «сущность-связь» представлена в Приложении Е.
Реляционная база данных состоит из нормализованных таблиц. В процессе загрузки и корректировки базы данных, для получения информации по запросам и вывода отчётов, а также для решения большинства задач необходим одновременный доступ к нескольким взаимосвязанным таблицам. Взаимосвязь между таблицами базы данных устанавливается реляционными соотношениями.
Связи, определенные в схеме данных, используются автоматически при разработке многотабличных форм, запросов, отчетов, существенно упрощая процесс их конструирования.
Программный продукт представлен проектом - Cinema, который имеет 4 связанных между собой таблицы:
Bilety - информация реализованных билетах;
Films - информация о всех имеющихся в кинотеатре фильмах;
Seansy - информация о времени проведения сеансов и стоимости билетов на эти сеансы;
Today - информация о фильмах, которые будут показаны на сегодняшний день.
Качество разработанной БД всецело зависит от качества выполнения отдельных этапов ее проектирования. Огромное значение имеет качественная разработка логической модели данных, так как она, с одной стороны, обеспечивает адекватность базы данных предметной области, а с другой стороны, определяет структуру физической БД и, следовательно, ее эксплуатационные характеристики.
Одни и те же данные могут группироваться в таблицы-отношения различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информационных объектов предметной области. Группировка атрибутов в отношениях должна быть рациональной, предельно сокращающей дублирование данных и упрощающей процедуры их обработки и обновления.
Определенный набор отношений обладает лучшими свойствами при включении, модификации и удалении данных, если он отвечает конкретным требованиям нормализации отношений.
Нормализация отношений – формальный аппарат ограничений на их формирование, который позволяет устранить дублирование данных, обеспечить их непротиворечивость и уменьшить затраты на поддержание БД.
На практике наиболее часто используются понятия первой, второй и третьей нормальных форм.
Отношение называется нормализованным или приведенным к первой нормальной форме (1НФ), если все его атрибуты простые или атомарные (далее – неделимые). Отношение, находящееся в первой нормальной форме, будет иметь следующие свойства:
■ в отношении нет одинаковых кортежей;
■ кортежи не упорядочены;
■ атрибуты не упорядочены и различаются по наименованиям;
■ все значения атрибутов атомарные.
Как видно из перечисленных свойств, любое отношение автоматически находится в первой нормальной форме.
Легко показывается, что первая нормальная форма допускает хранение в одном отношении разнородной информации, избыточности данных, приводящих к неадекватности логической модели данных предметной области. Таким образом, первой нормальной формы недостаточно для правильного моделирования данных.
Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснение понятию функциональной зависимости.
Пусть имеется отношение R. Множество атрибутов У функционально зависимо от множества атрибутов X, если для любого состояния отношения R для любых кортежейиз того, чтоследует, что, т.е. во всех кортежах, имеющих одинаковые значения атрибутов X, значения атрибутов У также совпадают в любом состоянии отношения R.
Множество атрибутов X называется детерминантом функциональной зависимости , а множество атрибутов У – зависимой частью.
На практике эти зависимости отражают взаимосвязи, обнаруженные между объектами предметной области, и являются дополнительными ограничениями, определяемыми предметной областью. Таким образом, функциональная зависимость – семантическое понятие. Она возникает, когда по значениям одних данных в предметной области можно определить значения других данных. Например, зная табельный номер сотрудника, можно определить его фамилию. Функциональная зависимость задает дополнительные ограничения на данные, которые могут храниться в отношениях. Для корректности БД необходимо при выполнении операций модификации базы проверять все ограничения, определенные функциональными зависимостями.
Функциональная зависимость атрибутов отношения напоминает понятие зависимости в математике. Функциональная зависимость в математике – это тройка объектов X, Y и f , где Х множество, представляющее область определения функции, Y – множество значений, а f – правило, согласно которому каждому элементу ставится в соответствие один и только один элемент В противоположность этому в отношениях значение зависимого атрибута может принимать различные непредсказуемые значения в различных состояниях БД, соответствующих различным состояниям предметной области. Например, изменение сотрудником фамилии при вступлении в законный брак приведет к тому, что при том же значении детерминанта, скажем табельного номера, значение зависимого аргумента будет другим.
Функциональная зависимость атрибутов утверждает лишь то, что для каждого конкретного состояния БД по значению одного атрибута можно однозначно определить значение другого атрибута. Конкретные же значения зависимой части могут быть различны в различных состояниях БД.
Отношение находится во второй нормальной форме (2НФ), если оно находится в первой нормальной форме (1НФ) и нет неключевых атрибутов, зависящих от части составного ключа.
Из определения 2НФ следует, что если потенциальный ключ является простым, то отношение автоматически находится во второй нормальной форме.
Однако отношения, приведенные ко второй нормальной форме, все-таки содержат разнородную информацию и требуют написания дополнительного программного кода в виде триггеров для корректной работы БД. Следующим шагом по улучшению качества отношений является приведение их к третьей нормальной форме.
Отношение находится в третьей нормальной форме (ЗНФ), если оно находится в 2НФ и все неключевые атрибуты взаимно независимы.
Реляционная модель данных, состоящая из отношений, приведенных к 3НФ, является адекватной модели предметной области и требует наличия только тех триггеров, которые поддерживают ссылочную целостность. Такие триггеры являются стандартными, и их разработка не требует больших усилий.
Таким образом, разработку логической модели реляционной БД можно представить как определение отношений, отображающих понятия предметной области, и приведение их к третьей нормальной форме.
Алгоритм разработки включает в себя три этапа.
Этап I. Приведение к 1НФ. Здесь необходимо определить и задать отношения, отображающие понятия предметной области. Все отношения автоматически находятся в 1НФ.
Этап II. Приведение к 2НФ. Если в некоторых отношениях обнаружена зависимость атрибутов от части сложного ключа, то следует провести их декомпозицию следующим образом: атрибуты, которые зависят от части сложного ключа, выносятся в отдельное отношение вместе с этой частью ключа, а в исходном отношении остаются все ключевые атрибуты.
. Ключ– сложный ключ.
– зависимость всех атрибутов от ключа отношения;
– зависимость некоторых атрибутов от части сложного ключа.
– оставшаяся часть исходного отношения;
– новое отношение.
Этап III. Приведение к 3НФ. Если в некоторых отношениях обнаружена зависимость одних неключевых атрибутов от других нсключевых атрибутов, то проводится декомпозиция этих отношений: неключевые атрибуты, которые зависят от других неключевых атрибутов,
образуют отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости.
Пусть, например, исходное отношение –. К – ключ.
Тогда функциональные зависимости имеют следующий вид:
После декомпозиции отношения получим:
На практике достаточно редко разработка логической модели БД производится по приведенному алгоритму. Чаще используют различные варианты ER-диаграмм, поддерживаемые соответствующими CASE-средствами. Основные понятия ER-диаграмм излагаются в стандартах IDEF1 и IDEF1X. Однако приведенный алгоритм полезен как иллюстрация проблем, которые могут возникать при определении на первых этапах проектирования слабо нормализованных отношений. Понимание этих проблем особенно важно при проведении модификаций и доработок БД, когда вводятся новые сущности, появляются новые зависимости и т.п.
На рисунке 1 представлена логическая модель базы данных студенческого общежития.
Рисунок 1 – логическая модель
Логическая (даталогическая) модель представляет собой модель базы данных, которая не привязана к конкретной СУБД. В ней выделяют основные объекты БД и определяют связи между этими объектами. Иногда определятся типы данных отдельных объектов. Данная модель построена методом Сущность-связь (Entity Relationship).
2.2 Сущности
Данная БД содержит 16 сущностей. Разберем каждую из них и связи между ними.
Сущность Форм_об содержит два атрибута: Ном_фо – порядковый номер формы обучения, и Форм_об – форма обучения, первый из которых является ключевым. В этой сущности содержатся возможные варианты форм обучения (бюджетная и контрактная).
Сущность Статус также содержит два атрибута: Ном_ст – порядковый номер статуса (ключевой атрибут), и Статус – наименование статуса. Статус может принимать два значения: студент и аспирант.
Сущность Факультет содержит информацию о факультетах. Первый атрибут (ключевой) Ном_фак – порядковый номер факультета, второй атрибут Факультет – сокращенное наименование факультета.
Сущность Специальность содержит информацию о специальностях ВУЗа. В качестве атрибутов – порядковый номер и цифровое обозначение специальности.
Сущность Комната содержит номера комнат и количество свободных в них мест. Так как по условию не должно быть незаселенных комнат и в комнате всего 3 места, нужно будет выставить соответствующее ограничение на ввод данных.
Сущность Тарифы содержит порядковый номер тарифа, определяющие стоимость критерии – номер статуса и номер формы обучения, и саму стоимость тарифа.
Сущность Группа содержит номер группы, определяющие критерии – номер факультета и номер специальности, а также курс.
В сущности Личн_дан находится информация о личных данных студента. Его номер студенческого билета, фамилия, имя, отчество, номер и серия паспорта, дата рождения, место рождения, место прописки и место жительства.
Сущность Студент содержит номер студенческого билета, номер тарифа оплаты за проживание в общежитии, дату поступления в ВУЗ и дату окончания ВУЗа.
Сущность Изменения содержит информацию об изменениях, которые произошли во время учебы. В качестве атрибутов она содержит номер изменения, наименование факультета, номер специальности, номер курса, номер группы, номер формы обучения и номер статуса.
Сущность Студ_измен служит для связи сущностей Студент и Изменения . Она содержит номер изменения, номер студенческого билета и дату, когда произошло изменение.
Сущность Студ_груп также является связующей сущностей Студент и Группа . В ней содержатся номер студенческого билета, номер группы и информация об отчислении и восстановлении студентов.
Еще одна связующая сущность – Студ_комн . Предназначена для хранения номера переселения студентов, номера студенческого билета, номера комнаты и дат заселения и выселения.
Архив – сущность для хранения веселенных студентов. Содержит номер записи, номер студенческого билета и дату выселения.
В сущности Неуплата содержится порядковый номер неуплаты, номер студенческого билета студента, который не заплатил за проживание, и неоплаченные им месяц и год.
В сущности Родители содержится информация о родителях студента, такая как ФИО отца и матери и состояние их брака, что может потребоваться для выплат дополнительных пособий студенту.
Логические модели реализуются средствами так называемой логики предикатов.
Предикат – функция, принимающая только два значения – «истина» и «ложь» и предназначаемая для выражения свойств объектов и связей между ними.
Выражение, в котором подтверждается или опровергается наличие каких-либо свойств у объекта наз. высказыванием.
Константы логики предикатов служат для именования объектов предметной области.
Логические выражения (или высказывания) образуют атомарные (простейшие) формулы.
Интерпретация предикатов – множество всех допустимых связываний переменных с константами. При этом связывани я – подстановка констант вместо переменных.
Высказывание логически следует из заданных посылок. Оно истинно всегда, когда истинны посылки.
Наиболее простым языком логики является исчисление высказываний, в которых отсутствуют переменные. К каждому высказыванию можно приписать значение «истинно» или «ложно». Отдельные высказывания могут соединяться связками «и», «или», «не», которые называются бумейми операторами.
Основу исчисления высказываний составляют правила образования сложных высказываний из атомарных.
Пример сложных высказываний.
А – истинно и В – ложно.
А и В истинно.
А и В – логические высказывания, о которых можно сказать, что они истинны или ложны. Исчисление высказываний – недостаточно выразительное средство для обработки знаний, так как в нем не могут быть представлены выражения, включающие переменные с кванторами.
Исчисление предикатов с кванторами (логика предикатов) является расширением исчисления высказываний, в которых для выражения отношений предметной области могут использоваться предложения, включающие не только константы, но и переменные.
Предикаты: clear (a), clear (c), ontable (a), ontable (c), on (c,b), cube(a), cube(b), pyram.de(c).
В общем случае модели, основанные на логике предикатов, описываются формальной системой, которая задается четверкой:
М = {Т, Р, А, П}
Т – множество базовых элементов (алфавит)
Р – множество синтаксических правил, на которых можно строить синтаксически корректные предложения
А – множество аксиом или несколько синтаксически правильных предложений, заданных априорно
П – правила продукций (правило вывода или семантическое правило, с помощью которого можно расширить множество А, добавляя в него синтаксически правильные предложения
Главное преимущество логических моделей: возможность непосредственно запрограммировать механизм вывода логически правильных предложений. Однако, с помощью правил, задающих синтаксис языка, нельзя установить истинность или ложность того или иного высказывания. Это распространяется на все языки программирования, реализующие логику предикатов.
Высказывание может быть построено синтаксически правильно, но оказаться совершенно бессмысленным.
Логические модели представления и манипулирования знаний были особенно популярны в 70-х годах 20 века, особенно с появлением языка пролог.
По мере того, как в поле зрения исследователей включались все новые интеллектуальные задачи, стало ясно, что говорить о доказательном выводе можно в небольшом числе случаев, когда проблемная область, в которой решалась задача, формально описана и полностью известна. Но в большинстве задач, где интеллект человека позволяет найти решение, связанное с областями, где знания принципиально не полны, не точны и не корректны. При таких условиях речь может идти только о правдоподобном выводе, при котором окончательный результат получается лишь с некоторой оценкой уверенности в его истинности.
Поэтому дальнейшее развитие баз знаний, использующих логические модели, шло по пути работ в области так называемых индуктивных логик, логик «здравого смысла», логик «веры» и др. логических систем, имеющих мало общего с классической логикой.
ФРЕЙМ
Фрейм – структура данных для представления стереотипных ситуаций. Модель представления данных на основе фреймов использует концепцию организации памяти понимания и обучения человека, предложена в 1979 году М. Минским.
Фрейм (рамка) – единица представления знаний, детали которой могут изменятсяв соответствии с текущей ситуацией. Фрейм в каждый момент времени может быть дополнен различной информацией, касающейся способов его применения, последствий этого применения и т.п.
Структура фрейма – характеристика описываемой стереотипной ситуации и их значения, которые называются слотами и заполнителями слотов .
Структура:
(Имя фрейма: Имя слота 1 (значение слота 1); Имя слота 2 (значение слота2); . . . Имя слота N (значение слотаN))
Значением слота может быть практически что угодно: числа, формулы, тексты на естественном языке, программы, правила вывода или ссылка на другие слоты данного фрейма или других фреймов.
В качестве значения слота может быть значение слота более низкого уровня, что позволяет реализовать «принцип матрешки».
Фрейм – структура данных, представляющая стереотипную ситуацию. К каждому фрейму присоединяется несколько видов информации. Часть этой информации о том, как использовать фрейм, другая часть – о том, что можно ожидать далее, еще одна часть – что следует делать, если ожидания не подтвердятся.
Фрейм можно представить в виде своеобразной таблицы.
В таблице дополнительные столбцы предназначаются для описания способа получения слотом его значения и возможного присоединения к тому или иному слоту специальных процедур, что допускается в теории фреймов.
В качестве значения слота может выступать имя другого фрейма. Так образуются сети фреймов.
Существует несколько способов получения слотом значения во фрейм экземпляре:
1) по умолчанию от фрейма образца;
2) через наследование свойств от фрейма указанного в слоте АКО;
3) по формуле, указанной в слоте;
4) через присоединяющуюся процедуру;
5) явно из диалога с пользователем;
6) из БД.
Важнейшим свойством теории фреймов является так называемое наследование свойств. Это наследование происходит по АКО – связям. A KIND OF (AKO)
Слот АКО указывает на фрейм более высокого уровня иерархии, откуда неявно наследуются, т.е. переносятся, значения аналогичных слотов.
В сети фреймов на рисунке понятие «ученик» наследует свойства фреймов «ребенок» и «человек», которые находятся на более высоком уровне иерархии. Так, на вопрос «любят ли ученики сладкое», следует ответ «да», так как этим свойством обладают все дети, что указано во фрейме «ребенок».
Наследование может быть частичным, так как возраст учеников не наследуется из фрейма «ребенок», так как указан явно в своем собственном фрейме.
Различают статические и динамические системы фреймов.
В статических системах фреймов фреймы не могут быть изменены в процессе решения задачи, а в динамических системах фреймов этот допустимо.
В системах программирования, основанных на фреймах, говорят, что они являются объектно-ориентированными. Каждый фрейм соответствует некоторому объекту предметной области, а слоты содержат описывающие этот объект данные, т.е. в слотах содержатся значения признаков объекта.
Фрейм может быть представлен в виде списка свойств, а если использовать средства БД, то в виде записи.
Наиболее ярко достоинства фреймовых систем представления знаний проявляются в том случае, когда родовидовые связи изменяются нечасто и предметная область насчитывает немного исключений.
Во фреймовых системах данные о родовидовых связях хранятся явно как и значения других типов.
Значения слотов представляются в системе в единственном экземпляре, так как включаются только в один фрейм, описывающий наиболее общие понятия из всех тех, которые содержит слот с данным именем. Такое свойство систем фреймов обеспечивает экономное размещение базы знаний в памяти компьютера.
Еще одно достоинства фреймов – значение каждого слота может быть вычислено с помощью соответствующих процедур или найдено эвристическими методами. Фреймы позволяют манипулировать как декларативными, так и процедурными знаниями.
Недостатки фреймовых систем: относительно высокая сложность.
