Лекции по "Информатике"

таблица ПАЦИЕНТЫ
Код пациента	Имя пациента	Адрес пациента
1111	Иванов И.И.	Вишнёвая 10 – 10
1234	Петров П.П.	Виноградная 21 – 21
2345	Комаров К.К.	Зелёная 20 – 20
5432	Семёнов С.С.	Тенистая 10 - 10
2468	Сергеев С.С.	Вишнёвая 11 – 11

 

В традиционной терминологии можно сказать, что столбцы – это элементы данных, а строки – записи. Таблица ХИРУРГИ представляет объект ХИРУРГ.

 

таблица ХИРУРГИ
Номер патента	Имя хирурга
987	Егоров Е.Е.
864	Пирогов И.С..
753	Преображенский Ф.Ф.
999	Борменталь И.А.
642	Склифосовский А.А.

 

 

таблица ПАЦИЕНТ И ХИРУРГ
Код пациента	Номер патента	Дата операции	Операция	Препарат, назначенный после операции
1111	987	1.01.97	Удаление камней из желчного пузыря	Пенициллин
1234	864	12.06.96	Удаление  камней из почек	Димицилин
2345	753	5.04.99	Удаление катаракты	-
5432	999	23.04.96	Удаление тромба	Тетрациклин
2468	642	22.07.92	Удаление желчного пузыря	Димицилин
2345	987	15.04.99	Замещение роговицы глаза	-
5432	864	11.01.99	Удаление камней из желчного пузыря	Тетрациклин
2468	753	22.06.93	Удаление катаракты	-

 

 

таблица ПРЕПАРАТ
Препарат, назначенный после операции	Побочный эффект
Пенициллин	Сыпь
Тетрациклин	Лихорадка
Димицилин	-

Рис. 7.1. Реляционная БД.

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

Свойства отношений реляционной  модели данных:

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

Использование реляционной модели данных в СУБД было предложено в  1970 г. доктором Э.Ф. Коддом. Процесс выявления объектов и их взаимосвязей с помощью концепций реляционной модели и табличной формы представления называется процессом нормализации. Одним из главных достоинств реляционного подхода является его простота, и следовательно, доступность для понимания конечным пользователем. Для обеспечения связи между таблицами некоторые из них должны содержать общие атрибуты. Например, в таблицах ПАЦИЕНТЫ и ПАЦИЕНТ И ХИРУРГ имеется избыточный атрибут «Код пациента». В результате между некоторыми возникает избыточность по ключу. Однако, это не обязательно приводит к физической избыточности, поскольку таблицы отражают логическое представление пользователя.

Достоинства модели

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

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

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

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

Недостатки модели

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

Классификация реляционных СУБД

В настоящее время принято выделять три типа СУБД:

• с локальной архитектурой;
• с архитектурой файл/сервер;
• с архитектурой клиент/сервер.

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

Локальная архитектура

Достоинства:

• является самой недорогой;
• простота разработки;
• имеет наибольшую скорость обработки запросов.

Недостатки:

• доступ к БД имеет только один пользователь;
• с БД может работать только одно приложение.

Архитектура файл/сервер:

Достоинства

• не требует от администратора и программиста навыков работы с промышленными СУБД.

Недостатки:

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

Архитектура клиент/сервер:

Достоинства:

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

Недостатки:

• требует от администратора баз данных навыков работы с промышленными СУБД.
• дорогостоящая при разработке.

Язык SQL

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

Язык SQL (произносят «эс-ку-эль») в настоящее время является промышленным стандартом, который в большей или меньшей степени поддерживает любая СУБД, претендующая на звание «реляционной». В то же время SQL подвергается суровой критике как раз за недостаточное соответствие реляционным принципам.

Из истории SQL

В начале 70-х годов в компании IBM была разработана экспериментальная  СУБД System R на основе языка SEQUEL (Structured English Qeury Language - структурированный английский язык запросов), который можно считать непосредственным предшественником SQL. Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования. В 1981 году IBM объявила о своём первом, основанном на SQL программном продукте, SQL/DS. Чуть позже к ней присоединились Oracle и другие производители. Первый стандарт языка SQL был принят Американским национальным институтом стандартизации (ANSI) в 1987 (так называемый SQL level 1) и несколько уточнён в 1989 году (SQL level 2). Дальнейшее развитие языка поставщиками СУБД потребовало принятия в 1992 нового расширенного стандарта (ANSI SQL-92 или просто SQL-2). В настоящее время ведётся работа по подготовке третьего стандарта SQL, который должен включать элементы объектно-ориентрованного доступа к данным.

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

В SQL определены два подмножества языка:

• SQL-DDL (Data Definition Language) - язык определения структур и ограничений целостности баз данных. Сюда относятся команды создания и удаления баз данных; создания, изменения и удаления таблиц; управления пользователями и т.д.
• SQL-DML (Data Manipulation Language) - язык манипулирования данными: добавление, изменение, удаление и извлечение данных, управления транзакциями.

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

Принципы, реализуемые реляционными СУБД

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

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

Перечислим эти правила:

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

• определение данных;
• определение правил целостности;
• манипулирование данными (в диалоге и из программы);
• определение таблиц-представлений и возможности их модификации;
• определение правил авторизации;
• определение границ транзакций.

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

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

Лекция 09: Введение в искусственный  интеллект

История развития

История развития искусственного интеллекта за рубежом

Идея создания искусственного подобия  человеческого разума для решения  сложных задач и моделирования мыслительной способности витала в воздухе с древнейших времен. Впервые её выразил Р.Луллий (ок.1235-ок.1315), который ещё в XIV в. пытался создать машину для решения различных задач на основе всеобщей классификации понятий.