Основы информационных систем

Основные принципы организации и обработки больших массивов данных (информационных систем) об объектах и явлениях реального мира. Фактографические и документальные информационные системы. Текстовые документы и базы данных. Объекты, атрибуты и связи.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 22.11.2012
Размер файла 80,2 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Содержание

  • Основы информационных систем
  • Базы данных
  • Текстовые документы и базы данных
  • Объекты, атрибуты и связи
  • Основные типы данных
  • Опыт проектирования таблиц - шахматная база данных
  • Иерархическая структура

Основы информационных систем

Нам предстоит познакомиться с основными принципами организации и обработки больших массивов данных об объектах и явлениях реального мира. Такие массивы данных вместе с программно-аппаратными средствами для их обработки называют информационными системами (ИС).

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

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

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

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

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

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

· сценическое имя (не более 12 произвольных символов);

· дата рождения в формате ДД. ММ. ГГГГ;

· пол (М или Ж);

· биография (произвольный текст);

· фонограмма с лучшим шлягером певца.

Располагая структурированными описателями (имя, дата, пол), система может выдать строгие ответы на вопросы: а) о любом певце персонально; б) о распределении певцов по возрасту и полу (в любых сочетаниях). Заметим, что те же данные в той или иной форме дублируются в биографии, например: "Б.В. Максимов (по сцене - Никита) родился 14 мая 1967 г. в семье.", "Лана Галина появилась на свет 5/10/72." и т.д. Однако, если удалить из списка структурированные описатели, система превратится в документальную и (если не принять мер) утратит способность находить и классифицировать артистов. В отличие от вас, компьютер "не знает", что Никита - мужчина, а Лана - женщина. Что 5/10/72 это 05.10.1972, что Галина - фамилия, а Галина - имя, что "родиться" и "появиться на свет" - синонимы и т.д.

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

Базы данных

Основа информационной системы, объект ее обработки - база данных.

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

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

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

Текстовые документы и базы данных

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

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

(а) текстового редактора как инструмента манипулирования текстами;

(б) группы текстовых файлов (базы данных) как объекта обработки.

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

Например, врач может поместить в файл карточки своих пациентов, с указанием фамилии, пола, даты рождения или возраста, диагноза и других данных, например: "Ветров С.И. /м/ЗЗ лет/Анемия", "Савченко Т. /ж/12.10.80/Ларингит" и т.п.

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

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

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

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

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

Если усложнить правила игры и соответственно - программу, можно научить машину отождествлять "Анемия" и "Анем.", но это другая тема, которой мы коснемся далее.

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

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

Теперь мы можем уточнить определение информационной системы.

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

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

Вопросы и задания

Что такое база данных?

Что такое банк данных?

Что такое информационная система?

В чем недостатки текстового файла как базы данных?

Приведите примеры баз данных из разных предметных областей.

Что такое структурирование информации?

Объекты, атрибуты и связи

Основные определения

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

информационная система база атрибут

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

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

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

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

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

Например, возьмем в качестве набора объектов классы школы. Число учеников в классе - это данное, которое принимает числовое значение (у одного класса 28, у другого - 32). Название класса - это данное, принимающее текстовое значение (у одного - 10А, у другого - 9Б и т.д.).

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

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

Атрибут некоторого набора объектов сам может быть набором объектов, имеющим собственные атрибуты. Например, атрибутом лица (как экземпляра набора объектов "Лица") является вуз, который это лицо окончило (МГУ, МИФИ и т.п.). С другой стороны, конкретный вуз - это экземпляр набора объектов "Вузы" и характеризуется множеством данных: фамилией ректора, адресом, специализацией, числом студентов и т.д. Наконец, ректор в свою очередь является экземпляром набора объектов "Лица". Таким образом, возникает возможность установления связи между экземплярами объектов из разных наборов.

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

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

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

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

Как составлять наборы объектов

Разработчик ИС (а иногда и пользователь) формирует набор объектов произвольно, исходя из смысла задачи и выбранного способа классификации данных. Например, в информационной системе "Вариант" предусмотрен набор объектов "События" (Конференция ЮНЕСКО, Первенство мира по футболу, Землетрясение в Иране и т.д.). - В качестве одного из атрибутов такого объекта используется категория события (политическое, спортивное, катастрофы и т.п.). Однако любое значение этого атрибута вы можете превратить в самостоятельный набор объектов и отдельно изучать, скажем, "Политические события", "Чрезвычайные происшествия" и т.д.

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

Как структурировать данные

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

Кроме того, разработчик определяет и сообщает ИС тип данного - текстовое, числовое и т.п., а также формат данного (например, формат даты).

Не следует смешивать "Имя данного" и "Значение данного". Имя данного в системе - только одно, например: Год рожд. Однако значения данного могут меняться (хотя и необязательно) при переходе от одного экземпляра объекта к другому (например, год рождения 1978, 1965, 1981 и проч.).

Как устанавливать связи

Во многих случаях связи между объектами обусловлены смыслом задачи и не зависят от произвола разработчиков. Например, далее мы будем рассматривать "классический" пример БД: "Заказы-Продукты-Клиенты". Здесь, в частности, мы имеем набор объектов "Заказы", и с каждым экземпляром этого набора (заказом) связаны экземпляр набора "Продукты" (т.е. что именно заказано, - например, "Пастила") и экземпляр набора "Клиенты" (т.е. заказчик, покупатель пастилы, - например, кафе "Парус").

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

Вопросы и задания

1. Что такое объект?

2. Что такое атрибут (данное)?

3. Приведите примеры материальных объектов.

4. Приведите примеры нематериальных, абстрактных объектов.

5. Приведите примеры качественных данных об объектах.

6. Может ли быть отметка, полученная учеником, объектом?

7. Что такое повторяющаяся группа?

8. Приведите примеры текстовых и числовых данных.

9. Чем отличается имя данного от значения данного?

10. Приведите примеры связей между данными.

Простая двумерная структура

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

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

Справочник состоит из однородных объектов - номеров телефонов. Выберем для объекта следующие данные:

· номер телефона;

· имя абонента (просто имя, или фамилия, или прозвище);

· адрес абонента;

· категория абонента (друзья, родственники, мастерские, магазины и т.д.).

Все данные будем считать текстовыми (символьными). Присвоим этим данным следующие имена и длины:

Имя данного

Пояснение

Длина

1)

Номер

Номер телефона

9

2)

Имя_аб

Обозначение абонента

15

3)

Адрес

Адрес абонента

40

4)

Катег

Категория абонента

2

В качестве данного "Категория" будем употреблять двухсимвольные коды-аббревиатуры: ДР - друзья, РД - родственники, СР - сервис, МН - магазины и т.п.

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

Таблица 1

Номер

Имя_аб

Адрес

Катег

233-08-19

Петров Евгений

Садовая, 18

ДР

265-04-15

Дядя Коля

Зеленая, 11

рд

570-14-20

Химчистка

Колышева, 5

СР

981-23-19

Эдик

-

МН

487-18-20

Терехов Анат. Дм.

Киевская, 2

рд

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

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

Если снабдить обе таблицы именами (например, ТЕLЕFОN (телефоны) и SLOVКАТ (словарь категорий)) и как-то перенести на диск компьютера, мы получим базу данных по телефонам, для которой уже можно использовать автоматизированные методы обработки.

Таблица 2

Катег

Наим_кат

ДР

Друзья

РД

Родственники

мн

Магазины

Компьютер сможет: (1) мгновенно выдать вам строку таблицы ТЕLЕFОN с указанным вами номером или, наоборот, с указанным именем абонента; (2) подать на экран список телефонов, упорядоченный по именам или категориям; (3) выбрать на экран телефоны заданной вами категории (например, только магазины); (4) напечатать любые выборки и многое другое. При этом в качестве категории может выдаваться не ее странный код, а точное наименование (из таблицы SLOVКАТ).

Заметим, что нашу базу данных образуют две простые двумерные таблицы (два списка) с фиксированным числом столбцов-данных (в таблице ТЕLЕFОN - 4, в SLOVКАТ - 2) и переменным числом строк-объектов (это число зависит от масштаба ваших контактов и меняется по мере появления новых знакомых или исчезновения старых).

Такое представление данных является наиболее простым и наглядным для человека и самым удобным - для машины.

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

Основные типы данных

Текстовые данные. Значение каждого текстового (символьного) данного представлено совокупностью произвольных алфавитно-цифровых символов, длина которой чаще всего не превышает 255 (например, 5, 10, 140). Текстовыми данными представляют в ИС фамилии и должности людей, названия фирм, продуктов, приборов и т.д. В частном случае значение текстового данного может быть именем какого-то файла, который содержит неструктурированную информацию произвольной длины (например, биографию или фотографию объекта). Фактически это структурированная ссылка, позволяющая резко расширить информативность вашей таблицы.

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

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

Данное типа даты и (или) времени. Данное типа даты задается в каком-то известном машине формате, например, - ДД. ММ. ГГ (день, месяц, год). С первого взгляда - это частный случай текстового данного. Однако использование в ИС особого типа для даты имеет следующие преимущества. Во-первых, система получает возможность вести жесткий контроль (например, значение месяца может быть только дискретным в диапазоне 01-12). Во-вторых, появляется возможность автоматизированного представления формата даты в зависимости от традиций той или иной страны (например, в США принят формат ММ-ДД-ГГ.). В-третьих, при программировании резко упрощаются арифметические операции с датами (попробуйте, например, вручную вычислить дату спустя 87 дней после заданного числа). Те же преимущества имеет использование данного типа времени.

Логические данные. Данное этого типа (иногда его называют булевым) может принимать только одно из двух взаимоисключающих значений - ТRUЕ или FALSЕ (условно: 1 или 0). Его значение можно интерпретировать как "Да" и "Нет" или как "Истина" и "Ложь". Логический тип удобно использовать для тех атрибутов, которые могут принимать одно из двух взаимоисключающих значений, например: наличие водительских прав (да-нет), исправность ручного тормоза (да-нет) и т.п.

Поле объекта ОLЕ (Object Linking and Embedding - связывание и внедрение объектов). Вероятно, это самый интересный "Значением" такого данного может быть любой объект ОLЕ, который имеется на вашем компьютере (графика, звук, видео). В частности, в свой телефонный справочник вы можете включить не только статическую фотографию дяди Пети, но и его голос, улыбку и походку.

Пользовательские типы. Во многих системах пользователям предоставляется возможность создавать собственные типы данных, например: "День недели" (понедельник, вторник и т.д.), "Адрес" (почтовый индекс - город - .) и др.

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

Вопросы и задания

Что такое поле?

Какие типы данных вы знаете?

Какие требования предъявляются к значениям данных типа даты? К значениям логических данных?

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

Что такое "поле объекта ОLЕ"?

Приведите примеры пользовательских типов данных.

Что означает выражение "Нет данных"?

В вашей системе имеется поле длиной 8 символов. Вы вводите в это поле дату: 32/06/95 (32 июня 1995 года). Как отреагирует система, если вы присвоили этому полю тип "Дата"? Как отреагирует система, если вы присвоили этому полю тип "Символы"?

Включите в таблицу ТЕLЕFОN поле, с помощью которого можно читать биографию абонента.

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

Опыт проектирования таблиц - шахматная база данных

Создадим шахматную систему - "Базу гроссмейстеров", которая будет содержать сведения обо всех партиях, сыгранных гроссмейстерами мира на официальных турнирах за определенный период, - например, с 1924 года. Как всегда, необходимо определить концептуальную основу системы, т.е. четко сформулировать требования и ограничения для информационной базы. Вот один из вариантов. (1) Будем учитывать только официальные турниры под эгидой ФИДЕ, т.е. сыгранные после 1924 года. (2) Будем учитывать только партии, в которых хотя бы один из партнеров являлся международным гроссмейстером, признанным ФИДЕ. Это означает, что в базу данных не попадут, с одной стороны, корифеи, игравшие до появления ФИДЕ (Стейниц, Чигорин), а с другой - гроссмейстеры "местного" значения. (Некоторые страны имели собственных гроссмейстеров, как и "домашних" генералиссимусов. И хотя по нашим условиям такой игрок в базу не попадет, это отнюдь не означает, что он играл хуже международного гроссмейстера).

Подскажем "стартовый" состав нашей базы:

дата партии (поле типа "Дата");

код белых;

код черных;

число ходов;

результат.

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

Алехин

Капабланка

Ботвинник и т.д.

Результат можно кодировать так: 2 - победа белых; 1 - ничья; 0 - поражение белых.

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

укажите страну (ввести словарь стран);

укажите дебют (словарь дебютов!);

введите комментарий к каждой партии (с изображением эндшпиля).

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

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

· на каком турнире игралась конкретная партия;

· какие партии игрались на первенство мира (подсказка: матч на первенство мира считать специальным случаем турнира ФИДЕ);

· кто главный судья турнира.

Придумайте три разных запроса к системе по образцу: "Какие партии выиграл Ботвинник, играя белыми, у Смыслова за 1948-1960 годы?"

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

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

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

Пусть имеются фирмы А и В. Фирма А изготавливает два вида продукции (например, трубы медные и полосы латунные), которые обозначим кодами 3980 и 1250. Каждый вид продукции можно изготавливать по разным технологическим схемам (в зависимости от свободного оборудования), при этом цена продукции получается разной. Продукция 3980 изготавливается по двум технологическим схемам с кодами 01 и 02, каждая из которых обеспечивает цену продукции соответственно 578 и 612 руб. /т. Продукция 1250 изготавливается по трем схемам 01, 02 и 03 с ценой 380, 345 и 410 руб. /т.

Фирма В изготавливает три вида продукции с кодами 1250, 1640 и 1930, для каждого из которых также имеются какие-то схемы и цены.

Мы хотим построить и поместить в память машины справочник цен, который содержит все фирмы, все виды продукции, их схемы и цены.

Описанную структуру данных можно представить себе как дерево, ствол которого - это набор объектов:

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

Фирма А

Фирма В

3980

1250

1250

1640

1930

01

02

01

02

03

578

612

380

345

410

Рис.

На стволе мы видим самые крупные узлы - фирмы. Из каждого такого узла растут ветки - виды продукции (для фирмы А - две ветки, для В - три ветки). От ветки 3980 фирмы А исходят две ветки-схемы, каждая из которых заканчивается "листочком"-ценой; от ветки 1250 фирмы А исходят три ветки-схемы с листочками на концах и т.д.

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

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

Фирма

Прод.

Схема

Цена

А

3980

01

578

А

3980

02

612

А

1250

01

380

А

1250

02

345

А

1250

03

410

В

1250

01

395

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

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

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

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

Что такое реляционный подход

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

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

Теория реляционных БД - это сложная математическая дисциплина, основы которой разработал в 70-годах доктор Э. Кодд (США). Основная терминология баз данных зависит от уровня описания (теория или практика), конкретного класса систем. (Мы свели терминологию в следующую таблицу.

Теория БД

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

Наши соглашения

Отношение (Relation)

Таблица (Таblе)

Таблица

Кортеж (Tuple)

Строка (Row)

Строка

Атрибут (Atribute)

Столбец (Соlumn)

Поле (field)

Примечание. В теории БД совместно с термином "Атрибут" (а иногда и вместо него) часто употребляют сочетание "Домен (domain) атрибута". Домен - это множество допустимых значений данного атрибута.

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

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

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

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

· уникальное имя поля;

· тип поля (тип данных);

· дополнительные характеристики (длину, формат).

Например, поле цена может иметь тип "Числовое" и длину 7 (4 знака до точки и 2 знака после точки).

4. Каждая строка таблицы на языке компьютера называется записью (rеcord). Система нумерует записи по порядку: 1, 2,., n, где n - общее число записей (строк) в таблице на данный момент. В отличие от количества полей (столбцов) в таблице, количество записей в процессе эксплуатации БД может как угодно меняться (от нуля до миллионов). Количество полей, их имена и типы тоже можно изменить, но это уже особая операция, которая называется изменением макета таблицы (или реорганизацией таблицы).

5. Каждое поле может входить в несколько таблиц (например, поле КАТЕГ (табл.1 и табл.2) входит в обе эти таблицы).

Далее мы будем рассматривать реляционный подход и принципы создания ИС в МS Ассеss на двух простых примерах. Пример 1 - это телефонный справочник, а пример 2 - простейшая система учета продаж торговой фирмы.

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

Таблица 1.3

Имя поля

Примечание

Тип поля

1)

Номер заказа

-

Число

2)

Код клиента

-

Число

3)

Наименование клиента

-

Текст

4)

Адрес клиента

-

Текст

5)

Код продукта

-

Число

6)

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

-

Текст

7)

Количество

кг

Число

8)

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

ДД. ММ. ГГГГ

Дата

9)

Цена

Руб. /кг

Число

10)

Стоимость

Руб.

Число

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

Вопросы и задания

Что такое макет таблицы?

Что такое домен?

Какими параметрами характеризуется макет таблицы?

Сколько строк может иметь реляционная таблица?

Кодирование информации

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

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

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

Непременное условие корректности кода - его уникальность. Это означает, что если вы присвоили, скажем, должности "старший бухгалтер" код 07, этот код не может принадлежать никакой другой должности.

Вопросы и задания

Что такое кодирование?

Перечислите преимущества кодирования.

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

Сколько знаков должен иметь код школьного предмета?

Сколько знаков должен иметь код ученика класса (школы, района)?

Первичный ключ таблицы

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

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

Однозначная идентификация записи: запись должна однозначно определяться значением ключа.

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

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

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

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

Почему мы говорим "Первичный ключ таблицы"? Бывают ли "вторичные" ключи? Да, кроме первичного, мы можем использовать так называемые простые (или вторичные) ключи таблицы. Например, в таблице TELEFON первичный ключ - номер телефона, однако мы можем просматривать эту таблицу по категории абонента, и тогда мы говорим, что поле катег - простой ключ таблицы. Значение простого ключа может быть неуникалъным. Первичный ключ может быть только один, а простых ключей - множество).

Ключи используются при упорядочивании (индексировании) таблиц.

Вопросы и задания

Какие бывают ключи у таблицы?

Какими свойствами обладает первичный ключ таблицы?

Укажите первичный ключ основного файла своей видеотеки. Если он не просматривается, введите первичный ключ. Объясните, почему вы выбрали его именно таким.

Приведите примеры простых ключей для таблиц по своему выбору.

Укажите первичный ключ "Базы гроссмейстеров".

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

Что такое нормализация

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

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

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

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

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

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

цена продукта;

стоимость продукта.

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

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

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

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

классификатор клиенты (код клиента, наименование клиента и адрес клиента);

классификатор продукты (код продукта, название продукта, цена).

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

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

При проектировании таких таблиц, как заказы, рекомендуем "золотые правила":

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

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

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

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

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

Повторяющиеся группы

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

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

Естественно желание разработчика включить в систему исчерпывающую информацию о работнике, объем которой от человека к человеку сильно меняется, а именно: прежняя работа, передвижение по службе, командировки, научные премии, взыскания, заболеваемость, печатные труды, увлечения и др. В принципе можно включить все это в основную таблицу, однако число полей придется брать по максимально возможному. Допустим, ученый может иметь до 30 премий. Тогда потребуется включить в таблицу 60 полей вида: дата!, Код1, ДАТА2, Код2,., где датаN - дата премии, а КодN - код премии. Большая часть значений этих полей в конкретных записях будет "пустой".

Такую информацию, разную по объему для каждого экземпляра объекта, называют повторяющимися группами. Задача решается просто, если для каждой повторяющейся группы завести отдельную таблицу, каждую со своим ключом. Например, можно создать таблицу премии с тремя столбцами: Табельный номер (НОМЕР), Дата присуждения (ДАТА), Код премии.

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

Одновременно в базу данных введем словарь SLPREM (СЛоварь ПРЕМий) с кодами и названиями премий: 01 - Нобелевская премия, 02 - Гонкуровская премия, 03 - золотая медаль имени Ломоносова и проч.

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

Достоверность информации

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

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

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

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

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

Вопросы и задания

Что такое нормализация?

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

Приведите примеры повторяющихся групп.

Что такое семантические ошибки в БД?


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.