Архитектура информационных систем

КОНСПЕКТ ЛЕКЦИЙ по дисциплине АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ для студентов 2 курса по направлению 230400 – Информационные системы и технологии План: 1. Основы информационного обеспечения процессов и систем. Понятие и содержание информационного обеспечения; Структура информационных систем; Классификация информационных систем. 2. Система представления и обработки данных в АИС Основные понятия; Модели представления данных; Сетевая модель; Иерархическая модель данных; Объектная модель; Гибридные модели; Реляционная модель данных; Нормализация данных. 3. Системы управления базами данных фактографических информационных систем Функции, классификация и структура СУБД; Функции СУБД; Языки баз данных; Язык определения данных; Языки манипулирования данными; Язык SQL; Трехуровневая архитектура СУБД. 4. Основы создания автоматизированных информационных систем Общие положения по созданию автоматизированных систем; Жизненный цикл БД АИС; Архитектура и проектирование информационных систем; Системный анализ предметной области; Инфологическое (семантическое) моделирование предметной области. 5. Распределенные информационные системы Понятие распределенных информационных систем, принципы их создания и функционирования; Технологии и модели «клиент-сервер»; Файловый сервер; Модель удаленного доступа к данным; Модель сервера баз данных; Сервер приложений. Трехуровневая модель. ОГЛАВЛЕНИЕ 1. Основы информационного обеспечения процессов и систем 4 1.1. Понятие и содержание информационного обеспечения 4 1.2 Структура информационных систем 8 1.2.1 Обеспечивающие подсистемы 8 1.2.2 Функциональные подсистемы 12 1.3. Классификация информационных систем 13 1.3.1 Классификация ИС по признаку структурированности задач 13 1.3.2. Классификация по степени автоматизации 16 1.3.3 Классификация по характеру использования информации 16 1.3.4. Классификация по сфере применения 17 1.3.5. Классификация по характеру представления и логической организации хранимой информации 18 1.3.6. Классификация по функциям и решаемым задачам 19 2. Система представления и обработки данных в АИС 20 2.1. Основные понятия 20 2.2. Модели представления данных 23 2.2.1. Иерархическая модель данных 24 2.2.2. Сетевая модель 25 2.2.3. Объектная модель 27 2.2.4. Гибридные модели 28 2.2.5. Реляционная модель 28 2.3. Реляционная модель данных 28 2.3.1. Базовые понятия реляционной модели данных 29 2.3.2. Связанные отношения 35 2.3.3. Внешние ключи отношения 36 2.3.4. Условия целостности данных 36 2.3.5. Типы связей между таблицами 38 2.3.6. Основные свойства отношений 39 2.3.7. Свойства таблиц реляционной базы данных 40 2.3.8. Индексы 40 2.4. Нормализация данных 42 2.4.1. Избыточность данных 43 2.4.2. Аномалии обновления 43 2.4.3. Аномалии удаления 43 2.4.4. Аномалии ввода 44 2.4.5. Нормальные формы 44 3. Системы управления базами данных фактографических информационных систем 48 3.1. Функции СУБД 48 3.2. Языки баз данных 55 3.2.1. Язык определения данных 55 3.2.2. Языки манипулирования данными 55 3.2.3. Язык SQL 57 3.3. Трехуровневая архитектура СУБД 61 4. Основы создания автоматизированных информационных систем 64 4.1. Общие положения по созданию автоматизированных систем 64 4.2. Жизненный цикл БД АИС 67 4.3. Архитектура и проектирование информационных систем 67 4.3.1. Стили проектирования ИС 67 4.3.2. Качество ИС 69 4.4 Системный анализ предметной области 75 4.5 Инфологическое (семантическое) моделирование предметной области 76 4.5.1 Модель «сущность-связь» 77 4.5.2 Степени бинарных связей 79 4.5.3 Пример построения модели «сущность-связь» 83 5. Распределенные информационные системы 86 5.1. Понятие распределенных информационных систем, принципы их создания и функционирования 87 5.2. Технологии и модели «Клиент-сервер» 90 5.2.1. Файловый сервер 91 5.2.2. Модель удаленного доступа к данным 92 5.2.3. Модель сервера баз данных 93 5.2.4. Сервер приложений. Трехуровневая модель 94 Список использованных источников 96 1. Основы информационного обеспечения процессов и систем 1.1. Понятие и содержание информационного обеспечения Информационное обеспечение является составной частью более широкого понятия информационных процессов. В нормативно-правовой трактовке информационные процессы определяются как «процессы создания, сбора, обработки, накопления, хранения, поиска, распространения и потребления информации и охватывают тем самым все сферы человеческой деятельности. Информационное обеспечение чаще всего соотносится с организационно-управленческой и производственно-технологической сферой. Поэтому под информационным обеспечением будем понимать совокупность процессов сбора, обработки, хранения, анализа и выдачи информации, необходимой для обеспечения управленческой деятельности и технологических процессов. Основополагающим в определении информационного обеспечения является понятие информации. Термин информация происходит от латинского informatio — разъяснение, изложение. До середины нашего столетия информация трактовалась как сведения, передаваемые людьми устным, письменным или другим (знаками, техническими средствами) способом. После 50-х годов на фоне бурного развития средств связи и телекоммуникаций, возникновения и внедрения в различные сферы жизни электронно-вычислительной техники появились новые, расширенные трактовки понятия информация. Информацию в вероятностно-статистическом (или энтропийном) подходе стали трактовать как уменьшение степени неопределенности знания о каком-либо объекте, системе, процессе или явлении, или изменение неопределенности состояния самого объекта, системы, явления, процесса. Такую трактовку по имени ее автора, американского математика К. Э. Шеннона еще называют информацией по Шеннону. Известна также и широко используется философская, или точнее говоря, общенаучная трактовка понятия информации как изменение объема и структуры знания воспринимающей системы. При этом под воспринимающей системой понимается не только собственно сам человек или его производные (коллектив, общество), но и, вообще говоря, любая система, например биологическая клетка, воспринимающая при рождении генетическую информацию. Существует еще и нормативно-правовая трактовка понятия информации, которая используется в законодательных актах, регламентирующих информационные процессы и технологии. Так, в частности, в законе РФ «Об информации, информатизации и защите информации» (от 20.02.95 № 24-ФЗ) дается следующее определение термина «информация» — сведения о лицах, предметах, фактах, событиях и процессах независимо от способа их представления. Добавим в связи с этим еще один важный нормативно-правовой аспект. Статья 128 Гражданского кодекса РФ информацию, наряду с вещами (включая деньги, ценные бумаги и иное имущество, в том числе имущественные права), работами и услугами, результатами интеллектуальной деятельности, нематериальными благами, определяет видом объектов гражданских прав, распространяя на нее тем самым весь институт гражданского права, включая права собственности и авторское право. Как представляется, в контексте рассмотрения содержания информационно-аналитической сферы наиболее подходящим является объединение общенаучной и нормативно-правовой трактовки понятия информации. Поэтому в дальнейшем информацию будем понимать как изменение объема и структуры знания о некоторой предметной области (лица, предметы, факты, события, явления, процессы) воспринимающей системой (человек, организационная структура, автоматизированная информационная система) независимо от формы и способа представления знания. При рассмотрении понятия информационного обеспечения в контексте обработки информации важное значение имеет понятие данных. От информации данные отличаются конкретной формой представления и являются некоторым ее подмножеством, определяемым целями и задачами сбора и обработки информации. К примеру, данные по сотрудникам какой-либо организации в виде формализованных учетных карточек кадрового подразделения содержат лишь некоторый перечень необходимых сведений (ФИО, год рождения, образование, семейное положение, должность и т. д.) в отличие от огромного количества сведений, характеризующих каждого конкретного человека. Поэтому определим данные как информацию, отражающую определенное состояние некоторой предметной области в конкретной форме представления и содержащую лишь наиболее существенные с точки зрения целей и задач сбора и обработки информации элементы образа отражаемого фрагмента действительности. Таким образом, информация на стадии данных характеризуется определенной формой представления и дополнительной характеристикой, выражаемой термином структура. Структура данных связана с понятием представления информации и определяется функциональной, логической, технологической и т. п. структурой той предметной области, информацию о которой содержат данные. Вместе с тем данные могут быть представлены и в неструктурированной форме, что предопределяет технологические особенности их накопления и обработки. Таким образом, можно выделить неструктурированную и структурированную форму представления данных. В качестве примера неструктурированной формы можно привести: • связный текст (т. е. документ на естественном языке — на литературном, официально-деловом и т. д.); • графические данные в виде фотографий, картинок и прочих неструктурированных изображений. Примерами структурированной формы данных являются: • анкеты; • таблицы; • графические данные в виде чертежей, схем, диаграмм. Способы сбора, анализа и обработки структурированных и неструктурированных данных существенно различаются. Наиболее развитыми в настоящее время, с точки зрения задач обработки и анализа информации, являются программные средства обработки структурированных данных, т. к. структуризацию можно считать первичной и наиболее трудно формализуемой и алгоритмизируемой обработкой. В плане оперирования с информацией в процессах ее создания (порождения), сбора, выдачи и потребления важное значение имеет понятие документированной информации или просто документа. Можно сказать, что в большом количестве случаев информация предстает и фигурирует в образе документа, исключая ту часть информационных процессов, которые оперируют исключительно с данными, как, например, в автоматизированных системах управления технологическими процессами — АСУТП, где информация порождается в виде показаний датчиков (входные данные), обрабатывается, выдается и потребляется в виде управляющих сигналов (выходные данные) на технологическое оборудование. Как и в случае с понятием самой информации, существует несколько трактовок термина документ — историческая, организационно-управленческая и нормативно-правовая трактовка. Исторически документ понимался (и в определенных случаях понимается сейчас) как объект, средство, способ для удостоверения личности, прав собственности и т. д. В организационно-управленческом смысле документ понимается как служебный или организационно-распорядительный документ, т. е. как форма и способ выражения организационно-управленческих решений и воздействий. В нормативно-правовом аспекте документ определяется как зафиксированная на материальном носителе информация с реквизитами, позволяющими ее идентифицировать. Под документированием информации в широком смысле слова можно понимать выделение единичной смысловой части информации (данных) по некоторой предметной области в общей ее массе, обособление этой части с приданием ему самостоятельной роли (имя, статус, реквизиты и т. п.). Процесс документирования превращает информацию в информационные ресурсы. Таким образом, документирование информации подводит к одному из самых фундаментальных понятий в сфере информационного обеспечения — информационным системам. Так же как и для понятий информации и документа, понятие информационной системы многогранно и имеет несколько определений и подходов. В нормативно-правовом смысле информационная система определяется как «организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе и с использованием средств вычислительной техники и связи, реализующих информационные процессы»''. В технологическом плане аспект использования средств вычислительной техники (СВТ) в информационных системах и обеспечение на этой основе автоматизации решения каких-либо задач проявляется в близком термине автоматизированная система — «система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций». Опыт, практика создания и использования автоматизированных информационных систем в различных сферах деятельности позволяет дать более широкое и универсальное определение, которое полнее отражает все аспекты их сущности. Под информационной системой в дальнейшем понимается организованная совокупность программно-технических и других вспомогательных средств, технологических процессов и функционально-определенных групп работников, обеспечивающих сбор, представление и накопление информационных ресурсов в определенной предметной области, поиск и выдачу сведений, необходимых для удовлетворения информационных потребностей установленного контингента пользователей — абонентов системы. Исторически первыми видами информационных систем являются архивы и библиотеки. Им присущи все атрибуты информационной системы. Они обеспечивают в какой-либо предметной области сбор данных, их представление и хранение в определенной форме (книго-, архивохранилища, каталоги и т. д.), в них определяется порядок использования информационных фондов (т. е. определены абоненты, режимы и способы выдачи информации — абонементы, читальные залы и т. п.). Информационные системы, в которых представление, хранение и обработка информации осуществляются с помощью вычислительной техники, называются автоматизированными, или сокращенно АИС. Автоматизированные информационные системы в настоящее время являются неотъемлемой частью современного инструментария информационного обеспечения различных видов деятельности и наиболее бурно развивающейся отраслью индустрии информационных технологий. 1.2 Структура информационных систем 1.2.1 Обеспечивающие подсистемы Структуру информационной системы составляет совокупность отдельных ее частей, называемых подсистемами. Подсистема - это часть системы, выделенная по какому-либо признаку. Общую структуру информационной системы можно рассматривать как совокупность подсистем независимо от сферы применения. В этом случае говорят о структурном признаке классификации, а подсистемы называют обеспечивающими. Таким образом, структура любой информационной системы может быть представлена совокупностью обеспечивающих подсистем (рис. 1). Рисунок 1 - Структура информационной системы как совокупность обеспечивающих подсистем Среди обеспечивающих подсистем обычно выделяют информационное, техническое, математическое, программное, организационное и правовое обеспечение. Информационное обеспечение Назначение подсистемы информационного обеспечения состоит в современном формировании и выдаче достоверной информации для принятия управленческих решений. Информационное обеспечение ‑ совокупность единой системы классификации и кодирования информации, унифицированных систем документации, схем информационных потоков, циркулирующих в организации, а также методология построения баз данных. Унифицированные системы документации создаются на государственном, республиканском, отраслевом и региональном уровнях. Главная цель - это обеспечение сопоставимости показателей различных сфер общественного производства. Разработаны стандарты, где устанавливаются требования: • к унифицированным системам документации; • к унифицированным формам документов различных уровней управления; • к составу и структуре реквизитов и показателей; • к порядку внедрения, ведения и регистрации унифицированных форм документов. Однако, несмотря на существование унифицированной системы документации, при обследовании большинства организаций постоянно выявляется целый комплекс типичных недостатков: • чрезвычайно большой объем документов для ручной обработки; • одни и те же показатели часто дублируются в разных документах; • работа с большим количеством документов отвлекает специалистов от решения непосредственных задач; • имеются показатели, которые создаются, но не используются, и др. Поэтому устранение указанных недостатков является одной из задач, стоящих при создании информационного обеспечения. Схемы информационных потоков отражают маршруты движения информации и ее объемы, места возникновения первичной информации и использования результатной информации. За счет анализа структуры подобных схем можно выработать меры по совершенствованию всей системы управления. Построение схем информационных потоков, позволяющих выявить объемы информации и провести ее детальный анализ, обеспечивает исключение дублирующей и неиспользуемой информации, а также классификацию и рациональное представление информации. Методология построения баз данных базируется на теоретических основах их проектирования. Для понимания концепции методологии приведем основные ее идеи в виде двух последовательно реализуемых на практике этапов: 1-й этап - обследование всех функциональных подразделений фирмы с целью: • понять специфику и структуру ее деятельности; • построить схему информационных потоков: • проанализировать существующую систему документооборота; • определить информационные объекты и соответствующий состав реквизитов (параметров, характеристик), описывающих их свойства и назначение. 2-й этап - построение концептуальной информационно-логической модели данных для обследованной на 1-м этапе сферы деятельности. В этой модели должны быть установлены и оптимизированы все связи между объектами и их реквизитами. Информационно-логическая модель является фундаментом, на котором будет создана база данных. Для создания информационного обеспечения необходимо: • ясное понимание целей, задач, функций всей системы управления организацией; • выявление движения информации от момента возникновения и до ее использования на различных уровнях управления, представленной для анализа в виде схем информационных потоков, • совершенствование системы документооборота; • наличие и использование системы классификации и кодирования; • владение методологией создания концептуальных информационно-логических моделей, отражающих взаимосвязь информации; • создание массивов информации на машинных носителях, что требует наличия современного технического обеспечения. Техническое обеспечение Техническое обеспечение - комплекс технических средств, предназначенных для работы информационной системы, а также соответствующая документация на эти средства и технологические процессы Комплекс технических средств составляют: • компьютеры любых моделей; • устройства сбора, накопления, обработки, передачи и вывода информации; • устройства передачи данных и линий связи; • оргтехника и устройства автоматического съема информации; • эксплуатационные материалы и др. Документацией оформляются предварительный выбор технических средств, организация их эксплуатации, технологический процесс обработки данных, технологическое оснащение. Документацию можно условно разделить на три группы: • общесистемную, включающую государственные и отраслевые стандарты по техническому обеспечению; • специализированную, содержащую комплекс методик по всем этапам разработки технического обеспечения; • нормативно-справочную, используемую при выполнении расчетов по техническому обеспечению. К настоящему времени сложились две основные формы организации технического обеспечения (формы использования технических средств): централизованная и частично или полностью децентрализованная. Централизованное техническое обеспечение базируется на использовании в информационной системе больших ЭВМ и вычислительных центров. Децентрализация технических средств предполагает реализацию функциональных подсистем на персональных компьютерах непосредственно на рабочих местах. Перспективным подходом следует считать, по-видимому, частично децентрализованный подход - организацию технического обеспечения на базе распределенных сетей, состоящих из персональных компьютеров и большой ЭВМ для хранения баз данных, общих для любых функциональных подсистем. Математическое и программное обеспечение Математическое и программное обеспечение - совокупность математических методов, моделей, алгоритмов и программ для реализации целей и задач информационной системы, а также нормального функционирования комплекса технических средств. К средствам математического обеспечения относятся: средства моделирования процессов управления; типовые задачи управления; методы математического программирования, математической статистики, теории массового обслуживания и др. В состав программного обеспечения входят общесистемные и специальные программные продукты, а также техническая документация. К общесистемному программному обеспечению относятся комплексы программ, ориентированных на пользователей и предназначенных для решения типовых задач обработки информации. Они служат для расширения функциональных возможностей компьютеров, контроля и управления процессом обработки данных. Специальное программное обеспечение представляет собой совокупность программ, разработанных при создании конкретной информационной системы. В его состав входят пакеты прикладных программ (ППП), реализующие разработанные модели разной степени адекватности, отражающие функционирование реального объекта. Техническая документация на разработку программных средств должна содержать описание задач, задание на алгоритмизацию, экономико-математическую модель задачи, контрольные примеры. Организационное обеспечение Организационное обеспечение - совокупность методов и средств, регламентирующих взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации информационной системы. Организационное обеспечение реализует следующие функции: • анализ существующей системы управления организацией, где будет использоваться ИС, и выявление задач, подлежащих автоматизации; • подготовку задач к решению на компьютере, включая техническое задание на проектирование ИС и технико-экономическое обоснование ее эффективности; • разработку управленческих решений по составу и структуре организации, методологии решения задач, направленных на повышение эффективности системы управления. Организационное обеспечение создается по результатам предпроектного обследования на 1-м этапе построения баз данных, с целями которого вы познакомились при рассмотрении информационного обеспечения. Правовое обеспечение Правовое обеспечение - совокупность правовых норм, определяющих создание, юридический статус и функционирование информационных систем, регламентирующих порядок получения, преобразования и использования информации. Главной целью правового обеспечения является укрепление законности. В состав правового обеспечения входят законы, указы, постановления государственных органов власти, приказы, инструкции и другие нормативные документы министерств, ведомств, организаций, местных органов власти. В правовом обеспечении можно выделить общую часть, регулирующую функционирование любой информационной системы, и локальную часть, регулирующую функционирование конкретной системы. Правовое обеспечение этапов разработки информационной системы включает нормативные акты, связанные с договорными отношениями разработчика и заказчика и правовым регулированием отклонений от договора. Правовое обеспечение этапов функционирования информационной системы включает: • статус информационной системы; • права, обязанности и ответственность персонала; • правовые положения отдельных видов процесса управления; • порядок создания и использования информации и др. 1.2.2 Функциональные подсистемы При рассмотрении структуры информационной системы с точки зрения ее функционирования в ее составе можно выделить три функциональные подсистемы, представленные на рис. 2. Рисунок 2 - Состав и функциональные группы информационной системы Организационно-технологическая подсистема сбора информации обеспечивает отбор и накопление данных в информационную систему и включает совокупность источников информации, организационно-технологические цепочки отбора информации для накопления в системе. Без правильно организованной, оперативно и эффективно действующей организационно-технологической подсистемы сбора информации невозможна эффективная организация функционирования всей информационной системы в целом. Подсистема представления и обработки информации составляет ядро информационной системы и является отражением представления разработчиками и абонентами системы структуры и картины предметной области, сведения о которой должна отражать информационная система. Подсистема представления и обработки информации является одним из наиболее сложных компонентов при разработке информационной системы. Нормативно-функциональная подсистема выдачи информации определяет пользователей, или иначе абонентов, системы, реализует целевой аспект назначения и выполнения задач информационной системы. 1.3. Классификация информационных систем 1.3.1 Классификация ИС по признаку структурированности задач При создании или при классификации информационных систем неизбежно возникают проблемы, связанные с формальным - математическим и алгоритмическим описанием решаемых задач. От степени формализации во многом зависят эффективность работы всей системы, а также уровень автоматизации, определяемый степенью участия человека при принятии решения на основе получаемой информации. Чем точнее математическое описание задачи, тем выше возможности компьютерной обработки данных и тем меньше степень участия человека в процессе ее решения. Это и определяет степень автоматизации задачи. Различают три типа задач, для которых создаются информационные системы: структурированные (формализуемые), неструктурированные (неформализуемые) и частично структурированные. Структурированная (формализуемая) задача - задача, где известны все ее элементы и взаимосвязи между ними. Неструктурированная (неформализуемая) задача - задача, в которой невозможно выделить элементы и установить между ними связи. В структурированной задаче удается выразить ее содержание в форме математической модели, имеющей точный алгоритм решения. Подобные задачи обычно приходится решать многократно, и они носят рутинный характер. Целью использования информационной системы для решения структурированных задач является полная автоматизация их решения, т.е. сведение роли человека к нулю. Решение неструктурированных задач из-за невозможности создания математического описания и разработки алгоритма связано с большими трудностями. Возможности использования здесь информационной системы невелики. Решение в таких случаях принимается человеком из эвристических соображений на основе своего опыта и, возможно, косвенной информации из разных источников. Заметим, что в практике работы любой организации существует сравнительно немного полностью структурированных или совершенно неструктурированных задач. О большинстве задач можно сказать, что известна лишь часть их элементов и связей между ними. Такие задачи называются частично структурированными. В этих условиях можно создать информационную систему. Получаемая в ней информация анализируется человеком, который будет играть определяющую роль. Такие информационные системы являются автоматизированными, так как в их функционировании принимает участие человек. Информационные системы, используемые для решения частично структурированных задач, подразделяются на два вида (рис. 3): - создающие управленческие отчеты и ориентированные главным образом на обработку данных (поиск, сортировку, агрегирование, фильтрацию). Используя сведения, содержащиеся в этих отчетах, управляющий принимает решение; Рисунок 3 - Классификация информационных систем по признаку структурированности решаемых задач - разрабатывающие возможные альтернативы решения. Принятие решения при этом сводится к выбору одной из предложенных альтернатив. Информационные системы, создающие управленческие отчеты, обеспечивают информационную поддержку пользователя, т.е. предоставляют доступ к информации в базе данных и ее частичную обработку. Процедуры манипулирования данными в информационной системе должны обеспечивать следующие возможности: • составление комбинаций данных, получаемых из различных источников; • быстрое добавление или исключение того или иного источника данных и автоматическое переключение источников при поиске данных; • управление данными с использованием возможностей систем управления базами данных; • логическую независимость данных этого типа от других баз данных, входящих в подсистему информационного обеспечения; • автоматическое отслеживание потока информации для наполнения баз данных. Информационные системы, разрабатывающие альтернативы решений, могут быть модельными и экспертными. Модельные информационные системы предоставляют пользователю математические, статические, финансовые и другие модели, использование которых облегчает выработку и оценку альтернатив решения. Пользователь может получить недостающую ему для принятия решения информацию путем установления диалога с моделью в процессе ее исследования. Основными функциями модельной информационной системы являются: • возможность работы в среде типовых математических моделей, включая решение основных задач моделирования типа "как сделать, чтобы?", "что будет, если?", анализ чувствительности и др.; • достаточно быстрая и адекватная интерпретация результатов моделирования; • оперативная подготовка и корректировка входных параметров и ограничений модели; • возможность графического отображения динамики модели; • возможность объяснения пользователю необходимых шагов формирования и работы модели. Экспертные информационные системы обеспечивают выработку и оценку возможных альтернатив пользователем за счет создания экспертных систем, связанных с обработкой знаний. Экспертная поддержка принимаемых пользователем решений реализуется на двух уровнях. Работа первого уровня экспертной поддержки исходит из концепции "типовых управленческих решений", в соответствии, с которой часто возникающие в процессе управления проблемные ситуации можно свести к некоторым однородным классам управленческих решений, т.е. к некоторому типовому набору альтернатив. Для реализации экспертной поддержки на этом уровне создается информационный фонд хранения и анализа типовых альтернатив. Если возникшая проблемная ситуация не ассоциируется с имеющимися классами типовых альтернатив, в работу должен вступать второй уровень экспертной поддержки управленческих решений. Этот уровень генерирует альтернативы на базе имеющихся в информационном фонде данных, правил преобразования и процедур оценки синтезированных альтернатив. 1.3.2. Классификация по степени автоматизации В зависимости от степени автоматизации информационных процессов в системе управления фирмой информационные системы определяются как ручные, автоматические, автоматизированные (рис. 4). Рисунок 4 - Классификация информационных систем по разным признакам Ручные ИС характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком. Например, о деятельности менеджера в фирме, где отсутствуют компьютеры, можно говорить, что он работает с ручной ИС. Автоматические ИС выполняют все операции по переработке информации без участия человека. Автоматизированные ИС предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль отводится компьютеру. В современном толковании в термин "информационная система" вкладывается обязательно понятие автоматизируемой системы. Автоматизированные ИС, учитывая их широкое использование в организации процессов управления, имеют различные модификации и могут быть классифицированы, например, по характеру использования информации и по сфере применения. 1.3.3 Классификация по характеру использования информации Информационно-поисковые системы (см. рис. 4) производят ввод, систематизацию, хранение, выдачу информации по запросу пользователя без сложных преобразований данных. Например, информационно-поисковая система в библиотеке, в железнодорожных и авиа-кассах продажи билетов. Информационно-решающие системы осуществляют все операции переработки информации по определенному алгоритму. Среди них можно провести классификацию по степени воздействия выработанной результатной информации на процесс принятия решений и выделить два класса: управляющие и советующие. Управляющие ИС вырабатывают информацию, на основании которой человек принимает решение. Для этих систем характерны тип задач расчетного характера и обработка больших объемов данных. Примером могут служить система оперативного планирования выпуска продукции, система бухгалтерского учета. Советующие ИС вырабатывают информацию, которая принимается человеком к сведению и не превращается немедленно в серию конкретных действий. Эти системы обладают более высокой степенью интеллекта, так как для них характерна обработка знаний, а не данных. 1.3.4. Классификация по сфере применения Информационные системы организационного управления (см. рис. 4) предназначены для автоматизации функций управленческого персонала. Учитывая наиболее широкое применение и разнообразие этого класса систем, часто любые информационные системы понимают именно в данном толковании. К этому классу относятся информационные системы управления как промышленными фирмами, так и непромышленными объектами: гостиницами, банками, торговыми фирмами и др. Основными функциями подобных систем являются: оперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное планирование, бухгалтерский учет, управление сбытом и снабжением и другие экономические и организационные задачи. ИС управления технологическими процессами (ТП) служат для автоматизации функций производственного персонала. Они широко используются при организации для поддержания технологического процесса в металлургической и машиностроительной промышленности. ИС автоматизированного проектирования (САПР) предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии. Основными функциями подобных систем являются: инженерные расчеты, создание графической документации (чертежей, схем, планов), создание проектной документации, моделирование проектируемых объектов. Интегрированные (корпоративные) ИС используются для автоматизации всех функций фирмы и охватывают весь цикл работ от проектирования до сбыта продукции. Создание таких систем весьма затруднительно, поскольку требует системного подхода с позиций главной цели, например получения прибыли, завоевания рынка сбыта и т.д. Такой подход может привести к существенным изменениям в самой структуре фирмы, на что может решиться не каждый управляющий. 1.3.5. Классификация по характеру представления и логической организации хранимой информации По характеру представления и логической организации хранимой информации АИС разделяются на фактографические, документальные и геоинформационные. Фактографические АИС накапливают и хранят данные в виде множества экземпляров одного или нескольких типов структурных элементов (информационных объектов). Каждый из таких экземпляров структурных элементов или некоторая их совокупность отражают сведения по какому-либо факту, событию и т. д., отделенному (вычлененному) от всех прочих сведений и фактов. Структура каждого типа информационного объекта состоит из конечного набора реквизитов, отражающих основные аспекты и характеристики сведений для объектов данной предметной области. К примеру, фактографическая АИС, накапливающая сведения по лицам, каждому конкретному лицу в базе данных ставит в соответствие запись, состоящую из определенного набора таких реквизитов, как фамилия, имя, отчество, год рождения, место работы, образование и т. д. Комплектование информационной базы в фактографических АИС включает, как правило, обязательный процесс структуризации входной информации из документального источника. Структуризация при этом осуществляется через определение (выделение, вычленение) экземпляров информационных объектов определенного типа, информация о которых имеется в документе, и заполнение их реквизитов. В документальных АИС единичным элементом информации является нерасчлененный на более мелкие элементы документ и информация при вводе (входной документ), как правило, не структурируется, или структурируется в ограниченном виде. Для вводимого документа могут устанавливаться некоторые формализованные позиции—дата изготовления, исполнитель, тематика и т. д. Некоторые виды документальных АИС обеспечивают установление логической взаимосвязи вводимых документов — соподчиненность по смысловому содержанию, взаимные отсылки по каким-либо критериям и т. п. Определение и установление такой взаимосвязи представляет собой сложную многокритериальную и многоаспектную аналитическую задачу, которая не может в полной мере быть формализована. В геоинформационных АИС данные организованы в виде отдельных информационных объектов (с определенным набором реквизитов), привязанных к общей электронной топографической основе (электронной карте). Геоинформационные системы применяются для информационного обеспечения в тех предметных областях, структура информационных объектов и процессов в которых имеет пространственно-географический компонент, например маршруты транспорта, коммунальное хозяйство и т. п. 1.3.6. Классификация по функциям и решаемым задачам Разработка и проектирование информационной системы начинаются с построения концептуальной модели ее использования. Концептуальная модель использования информационной системы определяет, прежде всего, круг конкретных задач и функций, обеспечиваемых созданием и эксплуатацией информационной системы, а также систему сбора, накопления и выдачи информации. Поэтому другим критерием классификации АИС являются функции и решаемые задачи, основными из которых могут являться: • справочные; • поисковые; • расчетные; • технологические. Справочные функции являются наиболее распространенным типом функций информационных систем и заключаются в предоставлении абонентам системы возможностей получения установочных данных на определенные классы объектов (Лица, Организации, Телефоны, Адреса и т. п.) с жестко или произвольно заданным набором сведений. Видами информационных систем, реализующих чисто справочные функции, являются всевозможные электронные справочники, картотеки, программные или аппаратные «электронные записные книжки» и их более развитые аналоги в виде т. н. персональных информационных систем. Системы, реализующие поисковые функции, являются наиболее широко распространенным классом информационных систем, которые чаще всего называют информационно-поисковыми системами (ИПС). ИПС в общем виде можно рассматривать как некое информационное пространство, задаваемое в терминах информационно-логического описания предметной области —«информационные объекты», «информационные связи». Пользователям ИПС предоставляется возможность поиска и получения сведений по различным поисковым образам в таком информационном пространстве. Расчетные функции информационных систем заключаются в обработке информации, находящейся в системе, по определенным расчетным алгоритмам для различных целей. К числу подобных задач относится вычисление определенных статистических характеристик и показателей по экземплярам различных типов объектов и отношений, данные по которым накапливаются в системе. Широко применяющейся разновидностью расчетных информационных систем являются различные системы автоматического проектирования, всевозможные бухгалтерские и финансово-экономические системы. Технологические функции информационных систем заключаются в автоматизации всего технологического цикла или отдельных его компонент, какой-либо производственной или организационной структуры. К системам, обеспечивающим подобные задачи, относится широкий класс автоматизированных систем управления (АСУ, АСУ ТП). Другой разновидностью технологических информационных систем являются системы автоматизации документооборота. Рассмотренная классификация автоматизированных информационных систем, как и всякая классификация, условна и на практике конкретная АИС может характеризоваться комплексным характером представления информации (например, являться фактографически-документальной системой) и решать комплекс справочных, поисковых, расчетных и технологических задач. 2. Система представления и обработки данных в АИС 2.1. Основные понятия Автоматизированная информационная система (АИС) — это система, реализующая автоматизированный сбор, обработку, манипулирование данными, функционирующая на основе ЭВМ и других технических средств и включающая соответствующее программное обеспечение (ПО) и персонал. В дальнейшем в этом качестве будет использоваться термин информационная система (ИС), который подразумевает понятие автоматизированная. Каждая ИС в зависимости от ее назначения имеет дело с той или иной частью реального мира, которую принято называть предметной областью (ПрО) системы. Выявление ПрО — это необходимый начальный этап разработки любой ИС. Именно на этом этапе определяются информационные потребности всей совокупности пользователей будущей системы, которые, в свою очередь, предопределяют содержание ее базы данных. Под задачами обработки данных обычно понимается специальный класс решаемых на ЭВМ задач, связанных с видом, хранением, сортировкой, отбором по заданному условию и группировкой записей однородной структуры. Отдельные программы или комплекс программ, реализующие автоматизацию решения прикладных задач обработки данных, называются приложениями. Одним из важнейших понятий в теории информационных систем является понятие информации. Под информацией понимаются любые сведения о каком-либо событии, процессе, объекте. Данные — это информация, представленная в определенном виде, позволяющем автоматизировать ее сбор, хранение и дальнейшую обработку человеком или информационным средством. Для компьютерных технологий данные — это информация в дискретном, фиксированном виде, удобная для хранения, обработки на ЭВМ, а также для передачи по каналам связи. Информационным ядром (информационным фондом) подсистемы представления и обработки информации АИС, или, говоря иначе, внутренним носителем знаний о предметной области является база данных (БД). Понятие базы данных является центральным в сфере технологий автоматизированных информационных систем. База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области, или иначе БД — это совокупность взаимосвязанных данных при такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений в определенной предметной области. БД состоит из множества связанных файлов. Другим фундаментальным понятием, непосредственно связанным с АИС, является система управления базами данных (СУБД), которая по ГОСТу определяется как «совокупность программ и языковых средств, предназначенных для управления данными в базе данных, ведения базы данных и обеспечения взаимодействия ее с прикладными программами». В настоящее время развитие СУБД как специального вида программного обеспечения для создания и эксплуатации АИС приводит к более широким функциям СУБД. Ввиду этого в расширенном толковании СУБД можно определить как комплекс программных средств, реализующих создание баз данных, их поддержание в актуальном состоянии, а таю/се обеспечивающих различным категориям пользователей возможность получать из БД необходимую информацию. Кратко сформулируем основные современные принципы организации систем управления базами данных. • Значительная часть современных СУБД способна работать на компьютерах различной архитектуры под управлением разных операционных систем. • Подавляющее большинство современных СУБД обеспечивают поддержку полной реляционной модели данных, обеспечивая целостность категорий и целостность на уровне ссылок. • Современные СУБД для определения данных и манипуляции ими опираются на принятые стандарты в области языков, а при обмене данными между различными СУБД базируются на существующих технологиях по обмену информацией. • Многие существующие СУБД относятся к так называемым сетевым СУБД, которые предназначены для поддержки многопользовательского режима работы с базой данных и поддержки возможности децентрализованного хранения данных. • Такие СУБД имеют развитые средства администрирования баз данных и средства защиты хранимой в них информации. • Подобные СУБД имеют средства подключения клиентских приложений. • Современные СУБД характеризуются опытами применения концепции фундаментальной идеи объектно-ориентированного подхода, способствующей повышению уровня абстракции баз данных, являющейся перспективным этапом на пути развития технологий баз данных. Информационные системы, созданные средствами технологии баз данных, иногда принято называть банками данных (БнД). БнД — это система специальным образом организованных данных: баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных. Банк данных (БнД) представляет собой совокупность конкретной базы данных, СУБД, прикладных компонентов АИС (набор входных и выходных форм, типовых запросов для решения информационно-технологических задач в конкретной предметной области), а также комплекса технических средств, на которых они реализованы. Таким образом, соотношение понятий БнД, СУБД и БД можно проиллюстрировать схемой, приведенной на рис. 5. Рисунок 5 - Соотношение понятий БнД, СУБД и БД БнД включает в себя: • одну или несколько БД; • СУБД; • словарь или каталог данных; • администратора (АБД); • вычислительную систему (ВС), включающую аппаратные (АС) и программные (ПС) средства; • обслуживающий персонал (ОП). Схематично это выглядит так, как показано на рис. 6. Рисунок 6 – Состав банка данных Дадим краткие определения новым составляющим этой схемы. Словарь или каталог данных служит для централизованного накопления и описания ресурса данных. Он содержит описание ПрО, сведения о структуре БД, о связях между элементами БД. Словарь данных можно рассматривать как часть самой базы данных. Администратор БД (АБД) — человек или группа лиц, которые принимают решения. Основные функции АБД: • участие в разработке БД; • контроль правильности функционирования БД. Вычислительная система (ВС) — включает программные (ПС) и аппаратные средства (АС). Приложения, относящиеся к ПС АИС и созданные средствами СУБД, относят к приложениям СУБД. Приложения, созданные вне среды СУБД с помощью систем программирования, использующих средства доступа к БД, к примеру, Delphi или Visual Studio, называют внешними приложениями. Обслуживающий персонал (ОП) — это лица, прямыми обязанностями которых является создание и поддержание корректного функционирования банка данных. Они ответственны за работу БнД и прикладного программного обеспечения. К обслуживающему персоналу относятся: разработчики и администраторы базы данных, аналитики, программисты. 2.2. Модели представления данных Модель – способ структурирования данных, описания взаимосвязей между данными. Очевидные требования к модели: • Модель должна быть достаточно универсальной, позволяя работать с данными различной структуры и сложности. • Модель должна допускать автоматическую обработку данных, т.е. должна быть реализуема программными средствами. • Модель должна быть наглядной, «прозрачной». Поскольку задача описания структуры данных средствами выбранной модели возлагается на разработчика (человека), чем сложнее модель – тем труднее избежать ошибок при проектировании. Ниже перечислены основные разновидности моделей представления данных, используемых или использовавшихся в прошлом. 2.2.1. Иерархическая модель данных Иерархическая модель представляет собой связный неориентированный граф древовидной структуры, объединяющий сегменты. Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева, а не произвольных графов. При этом граф-дерево обладает следующими свойствами (рис. 7): 1. имеется только одна вершина графа — корень, в которую не заходит ни одно ребро; 2. имеются вершины графа n-ого уровня, называемые исходными, куда заходит одно ребро (n-1) уровня; исходит из этого узла ноль, один или несколько порожденных узлов, которые называются потомками; 3. единственный проход к порожденному узлу лежит через его исходный узел; 4. каждый потомок может иметь только одного предка; 5. нет замкнутых петель или циклов; 6. сегмент, у которого нет потомков, называется листовым сегментом. Преобразование концептуальной модели в иерархическую модель данных. Рисунок 7 – Иерархическая модель данных Преобразование концептуальной модели в иерархическую структуру данных во многом схоже с преобразованием ее в сетевую модель, но и имеет некоторые отличия в связи с тем, что иерархическая модель требует организации всех данных в виде дерева. Ситуация значительно усложняется, если потомок в связи имеет не одного, а двух и более предков. Так как подобное положение является невозможным для иерархической модели, то отражаемая структура данных нуждается в преобразованиях, которые сводятся к замене одного дерева, например, двумя (если имеется два предка). В результате такого преобразования в базе данных появляется избыточность, так как единственно возможный выход из этой ситуации — дублирование данных. Но дублирование информации - это нежелательное явление в информационных системах. Из-за его присутствия возникает возможность нарушения непротиворечивости данных, при этом и объем памяти расходуется неэффективно, а, значит, оно должно быть минимизировано. Вносимая полученной структурой избыточность данных может быть ограничена при помощи виртуальных сегментов и указателей следующим образом. Сегмент запоминается полностью только один раз. Когда сегмент должен дублироваться в двух или более деревьях все последующие вхождения сегмента запоминаются как указатели на место хранения данного сегмента. Такие вхождения называются виртуальными сегментами. При их использовании избыточности данных не возникает, а требуется лишь дополнительная память для хранения указателей. 2.2.2. Сетевая модель Сетевая модель (рис. 8) опирается на математическую структуру, которая называется направленным графом. Направленный граф состоит из узлов, соединенных ребрами. В контексте моделей данных узлы представляют собой объекты в виде типов записей данных, а ребра — связи между объектами со степенью кардинальности «один к одному» или «один ко многим». Если говорить более точно, сетевая БД состоит из набора экземпляров каждого типа из заданного в схеме БД набора типов записей и набора экземпляров каждого типа из заданного набора типов связи. Основное отличие графовых форм представления данных в сетевой структуре данных от иерархической структуры данных состоит в том, что потомок в графе может иметь любое число предков. В технологии построения сетевой модели используются несколько различных типовых структур данных, главными из которых являются: типы записей и наборы. Для построения этих структур применяются такие конструктивные элементы, как элемент данных, агрегат. Структуризация данных базируется на концепциях агрегации и обобщения. Агрегация используется для композиции элементов данных в запись. Обобщение используется для объединения однотипных записей файлов. Рассмотрим основные элементы сетевой модели данных. Рисунок 8 – Сетевая модель данных Элемент данных — это наименьшая поименованная информационная единица данных, доступная пользователю (аналог – поле в файловой системе). Элемент данных должен иметь свой тип (не структурный, простой). Агрегат данных соответствует следующему уровню обобщения — поименованная совокупность элементов данных внутри записи или другого агрегата. Запись — конечный уровень агрегации. Каждая запись представляет собой именованную структуру, содержащую один или более именованных элементов данных, каждый из которых обладает своим особым форматом. Тип записей — это совокупность логически связанных экземпляров записей. Тип записей моделирует некоторый класс объектов реального мира. В качестве элемента данных могут быть использованы только простые типы, а в качестве агрегатов могут быть использованы сложные типы: вектор и повторяющаяся группа. Набор — это поименованная двухуровневая иерархическая структура, которая содержит запись владельца и записи членов. Наборы выражают связи «один ко многим» или «один к одному» между двумя типами записей. Тип набора поддерживает работу с внутренними структурами типов записей. Тип набора — это не аналог файла, он определяет связь между типами записей. Каждый экземпляр типа набора может содержать только один экземпляр записи владельца и сколько угодно экземпляров записей членов. База данных в сетевой модели данных — это поименованная совокупность экземпляров записей различного типа и экземпляров наборов, содержащих связи между ними. Преобразование концептуальной модели в сетевую. Сетевая модель данных может быть без осложнений получена из концептуальной модели. Для этого надо предположить, что в последней используются только бинарные связи. Причем они должны принадлежать к типам «один к одному» или «один ко многим». При этом вместо объектов концептуальной модели необходимо использовать типы записей сетевой модели, где имена объектов становятся именами типов записей, атрибуты объектов становятся полями записей, связь между объектами превращается в связь между типами записей. Бинарные связи, принадлежащие к типу «один ко многим», переносятся в сетевую модель следующим образом: тип записи со стороны «один» становится владельцем, а тип записи со стороны «много» становится типом записи-члена. Для связи типа «один к одному» выбор типа записи – владельца и типа записи-члена может быть осуществлен произвольно. Присущие сетевым моделям внутренние ограничения не позволяют напрямую моделировать некоторые реально существующие в предметной области типы связей. К таким типам связей относятся рекурсивные связи и связи типа M:N. Для того чтобы их отразить в сетевой модели, применяют различные подходы, которые приводят к определенным преобразованиям графа. 2.2.3. Объектная модель В этой модели данные представляются в форме объектов. Объект имеет набор свойств, называемых атрибутами, и может включать в себя также процедуры для обработки данных, которые называют методами. Объекты, имеющие одинаковые наборы атрибутов и различающиеся только их значениями, образуют некоторый класс объектов. Например, класс «клиент» может иметь следующие атрибуты: «фамилия», «имя», «отчество», «номер кредитной карты». Для каждого объекта из этого класса определены конкретные значения перечисленных атрибутов. Говорят, что объект является экземпляром класса. На основе существующего класса могут создаваться новые, наследующие свойства исходного. При этом исходный класс именуется родителем нового класса. Производный класс называют потомком исходного. При этом объекты – экземпляры класса-потомка принадлежат также и родительскому классу, поскольку обладают всеми его атрибутами. Пример: на основе класса «клиент» может быть определен класс «постоянный клиент». Новый класс наследует атрибуты родительского и при этом добавляется новый атрибут – «процент скидки». Все постоянные клиенты продолжают оставаться клиентами в прежнем понимании, но о них имеется еще и дополнительная информация. В настоящее время не существует единого подхода к реализации объектных баз данных. Объектный подход – набор общих принципов, которые могут применяться при проектировании различных приложений. 2.2.4. Гибридные модели В некоторых приложениях предпринимаются попытки смешения различных моделей представления данных. Пример такого смешения – объектно-реляционная модель. В ней использовано некоторое сходство между реляционной и объектной идеологией. Строки таблиц реляционной модели соответствуют объектам объектной модели, столбцы таблиц – атрибутам объектов. Таблицы в целом являются аналогом классов. Отсюда вытекает возможность введения наследования при определении таблиц – таблица-потомок содержит те же столбцы, что и родительская, и, кроме того – дополнительные, определенные при наследовании. По идее создателей, объектно-реляционная модель должна унаследовать от реляционной легкость описания и манипулирования данными, а от объектной – возможность определения более сложных взаимоотношений между объектами. 2.2.5. Реляционная модель В реляционной модели (рис. 9) данные представляются в виде таблиц, состоящих из строк и столбцов. Каждая строка таблицы – информация об одном конкретном объекте, столбцы содержат свойства этого объекта. Взаимоотношения между объектами задаются с помощью связей между столбцами таблиц. Реляционная модель на сегодняшний день наиболее распространена. Она достаточно универсальна и проста в проектировании. Рисунок 9 – Реляционная модель За ряд преимуществ перед другими моделями представления данных реляционная модель на сегодняшний день является наиболее распространенной. Поэтому более подробное описание данной модели будет приведено в следующем пункте. 2.3. Реляционная модель данных Реляционная модель данных была предложена Э. Коддом, известным американским специалистом в области баз данных. Реляционная модель позволила решить одну из важнейших задач в управлении базами данных — обеспечить независимость представления и описания данных от прикладных программ, следствием чего стало бы существенное упрощение проектирования и программирования баз данных. К основным достоинствам реляционного подхода к управлению базой данных следует отнести: • наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными; • наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных; • возможность манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти. Несмотря на все свои достоинства, реляционные системы далеко не сразу получили широкое признание. Хотя уже во второй половине 70-х годов появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД. В настоящее время реляционные СУБД остаются одними из наиболее распространенных, несмотря на некоторые присущие им недостатки. Сейчас основным предметом критики реляционных СУБД является не их недостаточная эффективность, а некоторая ограниченность таких систем при использовании в так называемых нетрадиционных областях (наиболее распространенными примерами являются системы автоматизации проектирования), в которых требуются предельно сложные структуры данных. Причем эта ограниченность реляционных СУБД является прямым следствием их простоты и проявляется лишь в отдельных предметных областях. Вторым, часто отмечаемым, недостатком реляционных баз данных является невозможность адекватного отражения семантики предметной области — средства представления знаний о семантической специфике предметной области в реляционных системах очень ограничены. На устранение именно этих недостатков в основном и направлены исследования по созданию объектно-ориентированных баз данных. 2.3.1. Базовые понятия реляционной модели данных Термин «реляционный» указывает, прежде всего, на то, что такая модель хранения данных построена на взаимоотношении составляющих ее частей, которые удобно представлять в виде двухмерной таблицы. Как показал Кодд, набор отношений (таблиц) может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. Таким образом, реляционная модель данных представляет информацию в виде совокупности взаимосвязанных таблиц, которые принято называть отношениями или реляциями. Основными понятиями реляционной модели данных являются: • тип данных; • домен; • атрибут; • кортеж; • ключ. Рассмотрим смысл этих понятий на примере отношения (таблицы) СТУДЕНТЫ, содержащего информацию о студентах некоторого вуза (табл. 1). Таблица 1 - Пример отношения СТУДЕНТЫ реляционной базы данных №_студенческого_билета Имя Дата рождения Курс Специальность 23980282 Алексеев Д. А 12.03.1982 2 Биология 22991380 Яковлев Н. В 25.12.1979 4 Физика 22657879 Михайлов В. В 28.02.1979 5 Математика 24356783 Афанасьев А. В 19.08.1983 1 Иностранный язык 24350283 Кузнецов В. И 03.10.1982 1 Физика 23125681 СмирновА. Д 26.03.1981 3 История Тип данных Понятие типа данных в реляционной модели данных полностью эквивалентно соответствующему понятию в алгоритмических языках. Набор поддерживаемых типов данных определяется СУБД и может значительно различаться в разных системах. Однако практически все СУБД поддерживают следующие типы данных: • целочисленные; • вещественные; • строковые; • специализированные типы данных для денежных величин; • специальные типы данных для временных величин (дата и/или время); • типы двоичных объектов — данный тип не имеет аналога в языках программирования; обычно для его обозначения используется аббревиатура BLOB (Binary Large Object — большой двоичный объект). В рассматриваемом примере (см. табл. 1) используются три типа данных: строковый (столбцы Имя и Специальность), временной (столбец Дата_рождения) и целочисленный (Курс и №_студенческого_билета). Домен Наименьшая единица данных реляционной модели — это отдельное атомарное (неразложимое) для данной модели значение данных. Доменом называется множество атомарных значений одного и того же типа. Иными словами, домен представляет собой допустимое потенциальное множество значений данного типа. В нашем примере для каждого столбца таблицы можно определить домен. • Домены Имена и Специальности для столбцов Имя и Специальность соответственно будут базироваться на строковом типе данных — в число их значений могут входить только те строки, которые могут представлять имя и название специальности (в частности, такие строки не должны начинаться с мягкого знака). • Домен Даты_рождения для столбца Дата_рождения определяется на базовом временном типе данных — данный домен содержит только допустимый диапазон дат рождения студентов. • Домены Номера_курсов и Номера_студенческих_билетов базируются на целочисленном типе — в число их значений могут входить только те целые числа, которые позволяют обозначить номер курса университета (обычно от 1 до 6) и номер студенческого билета (обязательно положительное число). Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, если они относятся к одному домену. Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла. В нашем примере значения доменов Номера_курсов и Номера_студенческих_билетов, хотя и основаны на одном типе данных — целочисленном, сравнимыми не являются. Атрибуты, схема отношения, схема базы данных Столбцы отношения называют атрибутами, им присваиваются имена, по которым к ним затем производится обращение. Список имен атрибутов отношения с указанием имен доменов (или типов, если домены не поддерживаются) называется схемой отношения. Схема нашего отношения СТУДЕНТ запишется так: СТУДЕНТ {№_студенческого_билета Номера_студенческих_билетов Пия Имена. Дата_рождения Даты_рождения, Курс Номера_курсов. Специальность Специальности} Степень отношения — это число его атрибутов. Отношение степени один называют унарным, степени два — бинарным, степени три — тернарным,..., степени n — n-арным. Степень отношения СТУДЕНТЫ равна пяти, то есть оно является 5-арным. Схемой базы данных называется множество именованных схем отношений. Кортеж Кортеж, соответствующий данной схеме отношения, представляет собой множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Аргумент значение является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень кортежа, то есть число элементов в нем, совпадает со степенью соответствующей схемы отношения. Иными словами, кортеж — это набор именованных значений заданного типа. Таким образом, отношение, по сути, является множеством кортежей, соответствующим одной схеме отношения. Схему отношения иногда называют также заголовком отношения, а отношение как набор кортежей — телом отношения. Кардинальным числом, или мощностью отношения называется число его кортежей. Мощность отношения СТУДЕНТЫ равна 6. В отличие от степени отношения, кардинальное число отношения изменяется во времени. Пустые значения В некоторых случаях какой-либо атрибут отношения может быть неприменим. Например, в рассматриваемом в качестве примера отношении СТУДЕНТЫ может также храниться информация о потенциальных абитуриентах, посещающих подготовительные курсы вуза. В этом случае неприменимыми оказываются атрибуты №_студенческого_билета и Курс (так как абитуриенты еще не поступили в вуз и, следовательно, не имеют студенческого билета и не могут быть отнесены к какому- либо курсу). Кроме того, иногда при вводе информации в строку реляционной таблицы некоторые данные могут быть неизвестными и выясняться позже (при поступлении на подготовительные курсы абитуриент может еще не определиться окончательно, на какую специальность он будет поступать). В обоих указанных случаях в поля, соответствующие неприменимым или неизвестным атрибутам, ничего не заносится, и строка записывается в базу данных с пустыми значениями этих атрибутов. Следует понимать, что пустое значение — это не ноль и не пустая строка, а неизвестное значение атрибута, которое не определено в данный момент времени и, в принципе, может быть определено позднее. Для обозначения пустых значений полей используется слово NULL. . Ключи отношения Поскольку отношение с математической точки зрения является множеством, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно заданный момент времени. Таким образом, в отношении всегда должен присутствовать некоторый атрибут (или набор атрибутов), однозначно определяющий каждый кортеж отношения и обеспечивающий уникальность строк таблицы. Такой атрибут (или набор атрибутов) называется первичным ключом отношения. Более строго определить понятие первичного ключа можно следующим образом. Если R — отношение с атрибутами A1, A2, ..., An, то множество атрибутов К = (Ai, Ai+1 ..., Am) отношения R является первичным ключом этого отношения тогда, и только тогда, когда удовлетворяются два независимых от времени условия: ◦ уникальность — в произвольный момент времени никакие два кортежа отношения R не имеют одного и того же значения для A1, A2, ..., An; ◦ минимальность — ни один из атрибутов Ai, Ai+1 ..., Am не может быть исключен из К без нарушения уникальности. Для каждого отношения свойством уникальности обладает, по крайней мере, полный набор его атрибутов. Однако требуется обеспечить также условие минимальности. Поэтому, как правило, в отношении всегда имеется один атрибут, обладающий свойством уникальности и являющийся первичным ключом. В зависимости от количества атрибутов, входящих в ключ, различают простые и сложные (или составные) ключи. Простой ключ — ключ, содержащий только один атрибут. В общем случае операции объединения выполняются быстрее в том случае, когда в качестве ключа используется самый короткий и самый простой из возможных типов данных. С этой точки зрения наилучшим образом подходит целочисленный тип, который имеет аппаратную поддержку для выполнения над ним логических операций. Сложный, или составной, ключ — это ключ, состоящий из нескольких атрибутов. Набор атрибутов, обладающий свойством уникальности, но не обладающий минимальностью, называется суперключом. Суперключ — сложный (составной) ключ с большим числом столбцов, чем необходимо для того, чтобы быть уникальным идентификатором. Такие ключи нередко используются на практике, так как избыточность может оказаться полезной пользователю. В зависимости от того, содержит ли атрибут, являющийся первичным ключом, какую-либо информацию, различают искусственные и естественные ключи. Искусственный, или суррогатный, ключ — это ключ, созданный самой СУБД или пользователем с помощью некоторой процедуры, но сам по себе не содержащий информации. Искусственный ключ используется для создания уникальных идентификаторов строк, когда сущность должна быть описана полностью, чтобы однозначно идентифицировать конкретный элемент. Искусственный ключ часто задействуют вместо значимого сложного ключа, который является слишком громоздким, чтобы применяться в реальной базе данных. Система поддерживает искусственный ключ, но он никогда не виден пользователю. Естественный ключ — это ключ, в который включены значимые атрибуты и который, таким образом, содержит информацию. В рассматриваемом нами, примере в качестве первичного ключа отношения СТУДЕНТЫ можно рассматривать атрибут №_студенческого_билета. Причем данный ключ является естественным, так как несет вполне определенную информацию. Каждый из типов первичных ключей имеет свои достоинства и недостатки; их обсуждению посвящено большое количество публикаций. Мы не будем проводить подробное их сравнение, а отметим лишь основные плюсы и минусы каждого из видов ключей. Основными достоинствами естественных ключей является то, что они несут вполне определенную информацию и их использование не приводит к необходимости добавлять в таблицы атрибуты, значения которых не имеют никакого смысла и требуются лишь для связи между отношениями. Иными словами, естественные ключи позволяют получить более компактную форму таблиц (без избыточных, неинформативных данных) и более естественные связи между ними. Основным же недостатком естественных ключей является то, что их использование весьма затруднительно в случае изменчивости предметной области. Следует понимать, что значения атрибутов первичного ключа не должны меняться. То есть однажды заданное значение первичного ключа для кортежа не может быть позже изменено. Такое требование ставится в основном для поддержания целостности базы данных. Связь между отношениями обычно устанавливается именно по первичному ключу, и его изменение приведет к нарушению этих связей или к необходимости изменения записей в нескольких таблицах. Даже в сравнительно простых базах данных это может вызвать ряд трудноразрешимых проблем. В некоторых реляционных СУБД допускается изменение первичного ключа. Иногда это бывает действительно полезно. Однако прибегать к этому следует лишь в случае крайней необходимости. Типичным примером изменчивой предметной области, в которой для сущности невозможно определить неизменяемый естественный ключ, является любая область с человеком в качестве сущности. Второй довольно существенный недостаток естественных ключей состоит в том, что, как правило, уникальные естественные ключи являются составными и содержат строковые атрибуты. Как уже отмечалось, максимальная скорость выполнения операций над данными обеспечивается при использовании простых целочисленных ключей. Таким образом, с точки зрения быстродействия системы естественные ключи часто оказываются неоптимальными. Оба недостатка естественных ключей можно преодолеть, определив в отношениях суррогатные ключи, представляющие собой некоторый универсальный атрибут, как правило, целочисленного типа, не зависящий ни от предметной области, ни, тем более, от структуры отношения, которое он идентифицирует. Таким образом, можно обеспечить уникальность и неизменность ключа (раз он никаким образом не зависит от предметной области, то никогда не возникнет необходимость изменять его). Однако за это приходится платить избыточностью данных в таблицах. В любой из таблиц может оказаться несколько наборов атрибутов, которые допустимо выбрать в качестве ключа. Такие наборы называются потенциальными или альтернативными ключами. Нередко в отношениях определяются так называемые вторичные ключи. Вторичный ключ представляет собой комбинацию атрибутов, отличную от комбинации, составляющей первичный ключ. Причем вторичные ключи не обязательно обладают свойством уникальности. При их определении могут задаваться следующие ограничения: • UNIQUE — ограничение уникальности, значения вторичных ключей при данном ограничении не могут дублироваться; • NOT NULL — при данном ограничении ни один из атрибутов, входящих в состав вторичного ключа, не может принимать значение NULL. Перекрывающиеся ключи — сложные ключи, которые имеют один или несколько общих столбцов. 2.3.2. Связанные отношения В реляционной модели данные представляются в виде совокупности взаимосвязанных таблиц. Подобное взаимоотношение между таблицами называется связью (relation). Таким образом, еще одним важным понятием реляционной модели является связь между отношениями. Данное отношение может быть связано с отношением УСПЕВАЕМОСТЬ, в котором содержатся сведения об успеваемости студентов по разным предметам. Фрагмент такого отношения может выглядеть так, как показано в табл. 2. Таблица 2. Фрагмент отношения УСПЕВАЕМОСТЬ, связанного с отношением СТУДЕНТЫ №_студенческого_билета Предмет Оценка 23980282 Высшая математика 4 23980282 Философия 5 22991380 Высшая математика 3 22991380 Философия NULL 22657879 Общая физика 5 24356783 Общая физика " NULL Атрибут №_студенческого_билета таблицы УСПЕВАЕМОСТЬ содержит идентификатор студента (в данном примере в качестве такого идентификатора используется номер студенческого билета). Если нужно узнать имя студента, соответствующее строкам в таблице УСПЕВАЕМОСТЬ, то следует поискать это же значение идентификатора студента в поле №_студенческого_билета таблицы СТУДЕНТЫ и в найденной строке прочесть значение поля Имя. Таким образом, связь между таблицами СТУДЕНТЫ и УСПЕВАЕМОСТЬ устанавливается по атрибуту №_студенческого_билета. При рассмотрении связанных таблиц важное значение имеет понятие внешнего ключа. Рассмотрим его более подробно. 2.3.3. Внешние ключи отношения В базах данных одни и те же имена атрибутов часто используются в разных отношениях. В рассматриваемом примере атрибут №_студенческого_билета присутствует как в отношении СТУДЕНТЫ, так и в отношении УСПЕВАЕМОСТЬ. В этом примере атрибут №_студенческого_билета иллюстрирует понятие внешнего ключа (foreign key). Внешний ключ — это атрибут (или множество атрибутов) одного отношения, являющийся ключом другого (или того же самого) отношения. Внешние ключи используются для установления логических связей между отношениями. Связь между двумя таблицами устанавливается путем присваивания значений внешнего ключа одной таблицы значениям ключа другой. Так же как и любые другие ключи, внешние ключи могут быть простыми либо составными. Часто связь между отношениями устанавливается по первичному ключу, то есть значениям внешнего ключа одного отношения присваиваются значения первичного ключа другого отношения. Однако это не является обязательным — в общем случае связь может устанавливаться и с помощью вторичных ключей. Кроме того, при установлении связей между таблицами необязательно требование уникальности ключа, по которому устанавливается связь. Атрибуты внешнего ключа необязательно должны иметь те же имена, что атрибуты ключа, которым они соответствуют. Например, в нашем примере можно было дать атрибуту №_студенческого_билета таблицы УСПЕВАЕМОСТЬ другое имя, например Студенческий_билет. Внешний ключ может ссылаться на ту же таблицу, к которой он принадлежит; в этом случае внешний ключ называется рекурсивным. 2.3.4. Условия целостности данных Чтобы информация, хранящаяся в базе данных, была однозначной и непротиворечивой, в реляционной модели устанавливаются некоторые ограничительные условия. Ограничительные условия — это правила, определяющие возможные значения данных. Они обеспечивают логическую основу для поддержания корректных значений данных в базе. Такие ограничения целостности позволяют свести к минимуму ошибки, возникающие при обновлении и обработке данных. Важнейшими ограничениями целостности данных являются: • категорийная целостность; • ссылочная целостность. Ограничение категорийной целостности заключается в следующем. Кортежи отношения представляют в базе данных элементы определенных объектов реального мира или, в соответствии с терминологией реляционных СУБД, категорий. Например, строка таблицы СТУДЕНТЫ представляет конкретного студента. Первичный ключ таблицы однозначно определяет каждый кортеж и, следовательно, каждый элемент категории. Таким образом, для извлечения данных, содержащихся в строке таблицы, или для манипулирования этими данными необходимо знать значение ключа для этой строки. Поэтому строка не может быть занесена в базу данных до тех пор, пока не будут определены все атрибуты ее первичного ключа. Это правило называется правилом категорийной целостности и кратко формулируется следующим образом: никакой атрибут первичного ключа строки не может быть пустым. Рассмотрим теперь понятие ссылочной целостности. Если две таблицы связаны между собой, то внешний ключ таблицы должен содержать только значения, уже имеющиеся среди значений ключа, по которому осуществляется связь. Если корректность значений внешних ключей не контролируется СУБД, то может нарушиться ссылочная целостность данных. Это можно пояснить на рассматриваемом примере следующим образом. Если удалить из таблицы СТУДЕНТЫ строку (например, при отчислении студента), имеющую хотя бы одну связанную с ней строку в таблице УСПЕВАЕМОСТЬ, то это приведет к тому, что в таблице УСПЕВАЕМОСТЬ останутся записи об успеваемости студента, который уже отчислен. Такая же ситуация будет наблюдаться и в том случае, если внешнему ключу таблицы УСПЕВАЕМОСТЬ ошибочно будет присвоено значение, отсутствующее в значениях ключа связанной таблицы. Ограничения категорийной и ссылочной целостности должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. Что же касается ссылочной целостности, то здесь обеспечение целостности выглядит несколько сложнее. При обновлении ссылающегося отношения (при вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. А вот при удалении кортежа из отношения, на которое ведет ссылка, можно использовать один из трех подходов, обеспечивающих ссылочную целостность: • запрещается производить удаление кортежа, на который существуют ссылки, то есть сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа; • при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа должно автоматически становиться неопределенным; • при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения должны автоматически удаляться все ссылающиеся кортежи (это называется каскадным удалением). В развитых реляционных СУБД обычно можно выбрать способ поддержания ссылочной целостности для каждой отдельной ситуации определения внешнего ключа. Конечно, для принятия такого решения необходимо анализировать требования конкретной прикладной области. 2.3.5. Типы связей между таблицами При установлении связи между двумя таблицами одна таблица будет являться главной (master), а вторая — подчиненной (detail). Различие между ними несколько упрощенно можно пояснить следующим образом. В главной таблице всегда доступны все содержащиеся в ней записи. В подчиненной же таблице доступны только те записи, у которых значение атрибутов внешнего ключа совпадает со> значением соответствующих атрибутов текущей записи главной таблицы. Причем изменение текущей записи главной таблицы приведет к изменению множества доступных записей подчиненной таблицы, а изменение текущей записи в подчиненной таблице не вызовет никаких изменений ни в одной из таблиц. На практике часто связывают более двух таблиц. Одна и та же таблица может быть главной по отношению к одной таблице и подчиненной по отношению к другой. Или у одной главной таблицы может находиться в подчинении не одна, а несколько таблиц. Однако подчиненная таблица не может управляться двумя таблицами. Таким образом, у главной таблицы может быть несколько подчиненных, но у подчиненной таблицы может быть только одна главная. Различают четыре типа связей между таблицами реляционной базы данных: • один к одному — каждой записи одной таблицы соответствует только одна запись другой таблицы; • один ко многим — одной записи главной таблицы могут соответствовать несколько записей подчиненной таблицы; • многие к одному — нескольким записям главной таблицы может соответствовать одна и та же запись подчиненной таблицы; • многие ко многим — одна запись главной таблицы связана с несколькими записями подчиненной таблицы, а одна запись подчиненной таблицы связана с несколькими записями главной таблицы. Различие между связями типа «один ко многим» и «многие к одному» зависит от того, какая из таблиц выбирается в качестве главной, а какая — в качестве подчиненной. Например, если из связанных таблиц СТУДЕНТЫ и УСПЕВАЕМОСТЬ в качестве главной выбрать таблицу СТУДЕНТЫ, то получим связь типа «один ко многим». Если же выбрать в качестве главной таблицу УСПЕВАЕМОСТЬ, получится связь типа «многие к одному». 2.3.6. Основные свойства отношений Рассмотрим некоторые важнейшие свойства отношений реляционной модели данных. 1. Отсутствие упорядоченности кортежей В таблицах реляционной базы данных информация хранится в неупорядоченном виде. Упорядочивание в принципе не поддерживается СУБД и такое понятие как порядковый номер кортежа не имеет никакого смысла. Отсутствие упорядоченности кортежей отношения также является следствием определения отношения как множества кортежей. Поскольку не требуется поддержание порядка на множестве кортежей отношения, СУБД получает дополнительную гибкость при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. 2. Отсутствие упорядоченности атрибутов Атрибуты отношений также не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать схемы существующих отношений не только путем добавления новых атрибутов, но и путем удаления существующих атрибутов. Однако в большинстве существующих систем такая возможность не допускается, и хотя явная упорядоченность набора атрибутов отношения не требуется, часто для неявного упорядочения атрибутов используется их порядок в линейной форме определения схемы отношения. 3. Атомарность значений атрибутов Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений простого типа данных, то есть среди значений домена не могут содержаться множества значений (отношения). 4. Реляционная система управления базами данных Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц. Таким образом, реляционную базу данных можно рассматривать как хранилище данных, содержащее набор двухмерных связанных таблиц. Набор средств управления подобным хранилищем называется реляционной системой управления базами данных. Реляционная СУБД может содержать утилиты, приложения, службы, библиотеки, средства создания приложений и другие компоненты. В реляционной базе данных таблицы связаны между собой; это позволяет с помощью единственного запроса найти все необходимые данные (которые могут находиться в нескольких таблицах). Будучи связанной посредством общих ключевых полей, информация в реляционной базе данных может объединяться из множества таблиц в единый результирующий набор. 2.3.7. Свойства таблиц реляционной базы данных Так как таблицы в реляционной СУБД являются отношениями реляционной модели данных, то и свойства этих таблиц являются свойствами отношений, которые мы уже рассматривали. Кратко сформулируем эти свойства еще раз: • каждая таблица состоит из однотипных строк и имеет уникальное имя; • строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы), иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или NULL; • строки таблицы обязательно отличаются друг от друга хотя бы единственным значением, что позволяет однозначно идентифицировать любую строку; • столбцам таблицы присваиваются уникальные имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы); • полное информационное содержание базы данных представляется в виде явных значений данных, и такой метод представления является единственным, в частности не существует каких-либо специальных «связей» или указателей, соединяющих одну таблицу с другой; • при выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию — этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой строки или любого набора строк с указанными признаками. 2.3.8. Индексы Ранее мы рассмотрели понятие ключей таблиц базы данных. В большинстве реляционных СУБД ключи реализуются с помощью объектов, называемых индексами. Индекс представляет собой указатель на данные, размещенные в реляционной таблице. Можно провести аналогию индекса таблицы базы данных с алфавитным указателем, обычно помещаемым в конце книги. Чтобы найти в книге страницы, относящиеся к некоторой теме, проще всего обратиться к указателю, в котором устанавливается соответствие между перечисленными в алфавитном порядке темами и номерами страниц, и сразу определить требуемые страницы. Чтобы без указателя найти все страницы, относящиеся к нужной теме, пришлось бы просматривать всю книгу. Индекс базы данных предназначен для аналогичных целей — чтобы ускорить поиск информации в таблице базы данных. Индекс предоставляет информацию о точном физическом расположении данных в таблице. При создании индекса в нем сохраняется информация о местонахождении записей, относящихся к индексируемому столбцу таблицы. При добавлении в таблицу новых записей или удалении существующих индекс также модифицируется. При выполнении запроса к базе данных, в условие поиска которого входит индексированный столбец, поиск значений производится в первую очередь в индексе. Если этот поиск оказывается успешным, то в индексе устанавливается точное местоположение искомых данных в таблице базы данных. Рассмотрим пример индекса. На рис. 10 показан фрагмент таблицы СТУДЕНТЫ и индекса, построенного по полю Имя данной таблицы. При выполнении поиска по имени студента, просматривая индекс, можно сразу определить порядковый номер записи, содержащей необходимую информацию, и затем быстро найти в таблице сами данные. Если бы у таблицы отсутствовал индекс по полю Имя, то выполнение поиска по имени студента потребовало бы просмотра всей таблицы. Таким образом, использование индексов сокращает время выборки данных. Рисунок 10 - Поиск информации в таблице с помощью индекса Различают несколько типов индексов. Наиболее часто выделяют три типа: • простые; • составные; • уникальные. Простые индексы представляют собой простейший и вместе с тем наиболее распространенный тип индекса. Простой индекс строится на основе только одного столбца реляционной таблицы (индекс, приведенный на рис. 10, является простым). Составные индексы строятся по двум и более столбцам реляционной таблицы. При создании составного индекса необходимо принимать во внимание, что последовательность столбцов, по которым создается индекс, влияет на скорость поиска данных. Можно назвать два условия оптимальности следования столбцов в составном индексе: ◦ первым следует помещать столбец, содержащий наиболее ограничивающее значение (то есть содержащий меньшее количество повторов); ◦ первым следует помещать столбец, содержащий данные, которые чаще задаются в условиях поиска. Сформулированные условия оптимальности часто являются противоречивыми, так что между ними следует находить разумный компромисс. Уникальные индексы не допускают введения в таблицу дублирующих значений. Уникальные индексы используются не только с целью повышения скорости поиска, но и для поддержания целостности данных. Уникальный индекс может быть как простым, так и составным. 2.4. Нормализация данных Нормализация представляет собой процесс реорганизации данных путем ликвидации повторяющихся групп и иных противоречий с целью приведения таблиц к виду, позволяющему осуществлять непротиворечивое и корректное редактирование данных, . Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, то есть, исключена избыточность информации. Таким образом, нормализацию можно также определить как процесс, направленный на снижение избыточности информации в реляционной базе данных. Цели нормализации: Избыточность информации устраняется не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных и упрощения управления ими. Использование ненормализованных таблиц может привести к нарушению целостности данных (непротиворечивости информации) в базе данных. Обычно различают следующие проблемы, возникающие при наличии ненормализованных таблиц: • избыточность данных; • аномалии обновления; • аномалии удаления; • аномалии ввода. Чтобы проиллюстрировать проблемы, возникающие при работе с ненормализованными базами данных, рассмотрим в качестве примера таблицу СОТРУДНИКИ, содержащую информацию о сотрудниках некой организации. Структура этой таблицы приведена на рис. 11. Код сотрудника Имя Фамилия Отчество Дата рождения Адрес Телефон Должность Разряд Зарплата Рейтинг Дата приема Дата увольнения Рисунок 11- Структура ненормализованной таблицы СОТРУДНИКИ 2.4.1. Избыточность данных Избыточность данных проявляется в том, что в нескольких записях таблицы базы данных повторяется одна и та же информация. Например, один человек может работать на двух (или даже более) должностях. Но в таблице, приведенной на рис. 11, каждой должности соответствует запись, и в этой записи содержится информация о личных данных сотрудника, данную должность занимающего. Таким образом, если сотрудник работает на нескольких должностях, то его личные данные будут дублироваться несколько раз, что приведет к неоправданному увеличению занимаемого объема внешней памяти. 2.4.2. Аномалии обновления Аномалии обновления тесно связаны с избыточностью данных. Предположим, что у сотрудника, работающего на нескольких должностях, изменился адрес. Чтобы информация, содержащаяся в таблице, была корректной, необходимо будет внести изменения в несколько записей. Если же исправление будет внесено не во все записи, то возникнет несоответствие информации, которое и называется аномалией обновления. 2.4.3. Аномалии удаления Аномалии удаления возникают при удалении записей из ненормализованной таблицы. Пусть, например, в организации проводится сокращение штатов, и некоторые должности аннулируются. При этом следует удалить соответствующие записи в рассматриваемой таблице. Однако удаление приведет к потере информации о сотруднике, занимавшем эту должность. Такая потеря информации и называется аномалией удаления. (Для нашего случая можно привести и другой пример — удаление записи при увольнении сотрудника приведет к потере информации о должности, которую он занимал.) 2.4.4. Аномалии ввода Аномалии ввода возникают при добавлении в таблицу новых записей и обычно имеют место, когда для некоторых полей таблицы заданы ограничения NOT NULL. В таблице, рассматриваемой в качестве примера, имеется поле Рейтинг, в котором содержится информация об уровне квалификации сотрудника, устанавливаемом по результатам его работы. При приеме на работу нового сотрудника установить уровень его квалификации невозможно, так он еще не выполнял никаких работ в организации. Если для этого поля задать ограничение NOT NULL, то в таблицу нельзя будет ввести информацию о новом сотруднике. Это и называется аномалией ввода. Очевидно, что аномалии обновления, удаления и ввода крайне нежелательны. Чтобы свести к минимуму возможность появления такого рода аномалий, выполняется нормализация. 2.4.5. Нормальные формы Теория нормализации основана на концепции нормальных форм. Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если оно удовлетворяет свойственному данной форме набору ограничений. В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: • первая нормальная форма (1 Normal Form, INF); • вторая нормальная форма (2NF); • третья нормальная форма (3NF); • нормальная форма Бойса—Кодда (BCNF); • четвертая нормальная форма (4NF); • пятая нормальная форма, или нормальная форма проекции-соединения (5NF, или PJ/NF). Основные свойства нормальных форм: • каждая следующая нормальная форма в некотором смысле лучше предыдущей; • при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются. В основе процесса проектирования лежит метод нормализации — декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы. Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Функционально зависимым считается такой атрибут, значение которого однозначно определяется значением другого атрибута. Функционально зависимые атрибуты обозначаются следующим образом: X —> Y Эта запись означает, что если два кортежа в таблице имеют одно и то же значение атрибута X, то они имеют одно и то же значение атрибута Y. Атрибут, указываемый в левой части, называется детерминантом. Первая нормальная форма Ограничение первой нормальной формы — значения всех атрибутов отношения должны быть атомарными. Данное требование является базовым требованием классической реляционной модели данных, поэтому любая реляционная таблица по определению, уже находится в первой нормальной форме. Вторая нормальная форма Отношение находится во второй нормальной форме в том, и только в том случае, если это отношение находится в первой нормальной форме, и каждый неключевой атрибут полностью зависит от первичного ключа. Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги. 1. Определить, на какие части можно разбить первичный ключ, так чтобы некоторые из неключевых полей зависели от одной из этих частей (причем эти части могут содержать несколько атрибутов). 2. Создать новую таблицу для каждой такой части ключа и группы зависящих от нее полей и переместить их в эту таблицу. Часть бывшего первичного ключа станет при этом первичным ключом новой таблицы. 3. Удалить из исходной таблицы поля, перемещенные в другие таблицы, кроме тех из них, которые станут внешними ключами. В нашем примере для приведения таблицы СОТРУДНИКИ ко второй нормальной форме ее следует разделить на две таблицы. Первичный ключ исходной таблицы состоит из двух атрибутов — Код сотрудника и Должность. Все же личные данные о сотрудниках зависят только от атрибута Код сотрудника. Атрибуты, соответствующие этим данным, мы и выделим в качестве одной из таблиц, которую назовем ФИЗИЧЕСКИ Е ЛИЦА. Информацию же о их должностях и зарплате вынесем в другую таблицу, которой присвоим имя СОТРУДНИКИ. Схема приведения таблицы ко второй нормальной форме приведена на рис. 12. Полученные две таблицы связаны между собой по полю Код физического лица, которое является первичным ключом для таблицы ФИЗИЧЕСКИЕ ЛИЦА и внешним ключом для таблицы СОТРУДНИКИ. Данное поле отсутствовало в исходной таблице и было добавлено при проведении нормализации. Рисунок 12 - Приведение таблицы ко второй нормальной форме Третья нормальная форма Рассмотрим таблицу СОТРУДНИКИ, полученную после приведения исходной таблицы ко второй нормальной форме. Для этой таблицы существует функциональная связь между полями Код сотрудника и Зарплата. Однако эта функциональная связь является транзитивной. Функциональная зависимость атрибутов X и Y отношения R называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости X-»Z и Z -»Y, но отсутствует функциональная зависимость Z—> X. Транзитивность зависимости полей Код сотрудника и Зарплата означает, что заработная плата на самом деле является характеристикой не сотрудника, а должности, которую он занимает. В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату должности, до тех пор, пока не появится хотя бы один сотрудник, эту должность занимающий (так как первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника, занимающего данную должность, мы лишимся информации о заработной плате, соответствующей этой должности. Кроме того, чтобы согласованным образом изменить заработную плату, соответствующую должности, необходимо предварительно найти все записи, описывающие сотрудников, занимающих данную должность. Таким образом, в таблице СОТРУДИКИ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации — приведения базы данных к третьей нормальной форме. Отношение R находится в третьей нормальной форме в том, и только в том случае, если оно находится во второй нормальной форме, и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующие шаги. 1. Определить все поля (или группы полей), от которых зависят другие поля. 2. Создать новую таблицу для каждого такого поля (или группы полей) и группы зависящих от него полей и переместить их в эту таблицу. Поле (или группа полей), от которого зависят все остальные перемещенные поля, станет при этом первичным ключом новой таблицы. 3. Удалить перемещенные поля из исходной таблицы, оставив лишь те из них, которые станут внешними ключами. Приведем рассматриваемую в качестве примера базу данных к третьей нормальной форме. Для этого разделим таблицу СОТРУДНИКИ на две — СОТРУДНИКИ и ДОЛЖНОСТИ (рис. 13). Рисунок 13 - Приведение базы данных к третьей нормальной форме Обратите внимание, что мы опять добавили новый атрибут Код должности, который является первичным ключом для отношения ДОЛЖНОСТИ и внешним ключом для отношения СОТРУДНИКИ. Добавление новых атрибутов при нормализации позволяет получить таблицы с простыми первичными ключами, что облегчает выполнение операции связывания таблиц. Такие первичные ключи, как правило, являются искусственными. На практике третья нормальная форма схем отношений в большинстве случаев достаточна, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Поэтому мы не будем рассматривать другие нормальные формы, тем более что в работе они используются сравнительно редко. В заключение приведем схему базы данных, рассматриваемой в качестве примера и приведенной к третьей нормальной форме (рис. 14). Рисунок 14 - Структура базы данных, приведенной к третьей нормальной форме 3. Системы управления базами данных фактографических информационных систем 3.1. Функции СУБД С начала своего возникновения в конце 60-х годов автоматизированные информационные системы ориентировались на хранение и обработку больших объемов данных, которые не могли быть одновременно и полностью размещены в оперативной памяти ЭВМ. В структуре программного обеспечения ЭВМ, как в то время, так и сейчас, за организацию, размещение и оперирование данными во внешней (долговременной) памяти отвечает операционная система ЭВМ, соответствующий компонент которой чаще всего называется «файловой системой». Данные во внешней памяти компьютера представлены именованными совокупностями, называемыми файлами. В большинстве случаев операционная (файловая) система не «знает» внутренней смысловой логики организации данных в файлах и оперирует с ними как с однородной совокупностью байтов или строк символов. С точки зрения смысла и назначения АИС файлы данных имеют структуру, отражающую информационно-логическую схему предметной области АИС. Эта структура данных в файлах должна обязательно учитываться в операциях обработки (собственно, в этом и заключается одна из основных функций АИС). Вместе с тем, в силу невозможности в большинстве случаев размещения файлов баз данных сразу целиком в оперативной памяти компьютера, структуру данных в файлах баз данных приходится учитывать при организации операций обращения к файлам во внешней памяти. Отсюда вытекает основная особенность СУБД как вида программного обеспечения. Будучи по природе прикладным программным обеспечением, т. е. предназначенным для решения конкретных прикладных задач, СУБД изначально выполняли и системные функции — расширяли возможности файловых систем системного программного обеспечения. В общем плане можно выделить следующие функции, реализуемые современными СУБД: 1. Организация и поддержание логической структуры данных (схемы базы данных) обеспечивается средствами модели организации данных*. Модель данных определяется способом организации данных, ограничениями целостности и множеством операций, допустимых над объектами организации данных. Соответственно модель данных разделяют на три составляющие — структурную, целостную и манипуляционную. Термин целостность используется для описания корректности и непротиворечивости хранимых в БД данных. Реализация поддержки целостности данных предполагает, что СУБД должна содержать сведения о тех правилах, которые нельзя нарушать при работе с данными, и обладать инструментами контроля за тем, чтобы данные и их изменения соответствовали заданным правилам. Модель данных, реализуемая СУБД, является одной из основных компонент, определяющих функциональные возможности СУБД по отражению в базах данных информационно-логических схем предметных областей АИС. Модель организации данных, по сути, определяет внутренний информационный язык автоматизированного банка данных, реализующего автоматизированную информационную систему. Модели данных, поддерживаемые СУБД, довольно часто используются в качестве критерия для классификации СУБД. Исходя из этого, различают иерархические СУБД, сетевые СУБД и реляционные СУБД. 2. Организация и поддержание физической структуры данных во внешней памяти. Эта функция включает организацию и поддержание внутренней структуры файлов базы данных, иногда называемой форматом файлов базы данных, а также создание и поддержание специальных структур (индексы, страницы) для эффективного и упорядоченного доступа к данным. В этом плане эта функция тесно связана с третьей функцией СУБД — организацией доступа к данным. Организация и поддержание физической структуры данных во внешней памяти может производиться как на основе штатных средств файловых систем, так и на уровне непосредственного управления СУБД устройствами внешней памяти. 3. Организация доступа к данным и их обработка в оперативной и внешней памяти. Данная функция включает в себя несколько подфункций. 3.1 Поддержка транзакций. Организация доступа к данным и их обработка в оперативной и внешней памяти осуществляется через реализацию процессов, получивших название транзакций. Транзакцией называют последовательную совокупность операций, имеющую отдельное смысловое значение по отношению к текущему состоянию базы данных. Другими словами это набор действий, выполняемых с целью доступа или изменения содержимого базы данных. Так, например, транзакция по удалению отдельной записи в базе данных последовательно включает определение страницы файла данных, содержащей указанную запись, считывание и пересылку соответствующей страницы в буфер оперативной памяти, собственно удаление записи в буфере ОЗУ, проверку ограничений целостности по связям и другим параметрам после удаления и, наконец, «выталкивание» и фиксацию в файле базы данных нового состояния соответствующей страницы данных. Транзакции принято разделять на две разновидности — изменяющие состояние базы данных после завершения транзакции и изменяющие состояние БД лишь временно, с восстановлением исходного состояния данных после завершения транзакции. Совокупность функций СУБД по организации и управлению транзакциями называют монитором транзакций. Транзакции в теории и практике СУБД по отношению к базе данных выступают внешними процессами, отождествляемыми с действиями пользователей банка данных. При этом источником, инициатором транзакций может быть как один пользователь, так и несколько пользователей сразу. По этому критерию СУБД классифицируются на однопользовательские (или так называемые «настольные») и многопользовательские («тяжелые», «промышленные») СУБД. Соответственно в многопользовательских СУБД главной функцией монитора транзакций является обеспечение эффективного совместного выполнения транзакций над общими данными сразу от нескольких пользователей. 3.2 Обеспечение параллельного доступа. Одна из основных целей создания и использования СУБД заключается в том, чтобы множество пользователей могло осуществлять параллельный доступ к совместно обрабатываемым данным. Параллельный доступ сравнительно просто организовать, если все пользователи выполняют только чтение данных, поскольку в этом случае они не могут помешать друг другу. Однако когда два или больше пользователей одновременно получают доступ к базе данных, конфликт с нежелательными последствиями легко может возникнуть, например, если хотя бы один из них попытается обновить данные. СУБД должна гарантировать, что при одновременном доступе к базе данных многих пользователей подобных конфликтов не произойдет. 3.3 Управление буферами оперативной памяти. Непосредственная обработка и доступ к данным в большинстве СУБД осуществляется через организацию в оперативной памяти штатными средствами операционной системы или собственными средствами системы буферов оперативной памяти, куда на время обработки и доступа помещаются отдельные компоненты файла базы данных (страницы). Поэтому другой составной частью функций СУБД по организации доступа и обработки данных является управление буферами оперативной памяти. 3.4 Журнализация. Еще одной важной функцией СУБД с точки зрения организации доступа и обработки данных является так называемая журнализация всех текущих изменений базы данных. Журнализация представляет собой основное средство обеспечения сохранности данных при всевозможных сбоях и разрушениях данных. Во многих СУБД для нейтрализации подобных угроз создается журнал изменений базы данных с особым режимом хранения и размещения. Вместе с установкой режима периодического сохранения резервной копии БД журнал изменений2 при сбоях и разрушениях данных позволяет восстанавливать данные по произведенным изменениям с момента последнего резервирования до момента сбоя. Во многих предметных областях АИС (например, БД с финансово-хозяйственными данными) такие ситуации сбоя и порчи данных являются критическими и возможности восстановления данных обязательны для используемой СУБД. Кроме того СУБД реализует следующие не менее важные функции: 4. Восстановление базы данных Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: • мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания); • жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. 5. Контроль доступа к данным СУБД должна иметь механизм, гарантирующий возможность доступа к базе данных только санкционированных пользователей и защищающий ее от любого несанкционированного доступа. В современных СУБД поддерживается один из двух широко распространенных подходов к вопросу обеспечения безопасности данных: избирательный подход или обязательный подход. В большинстве современных систем предусматривается избирательный подход, при котором некий пользователь обладает различными правами при работе с разными объектами. Значительно реже применяется альтернативный, обязательный подход, где каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. 6. Ведение словаря данных Одной из основополагающих идей рассмотренной выше трехуровневой архитектуры является наличие интегрированного системного каталога с данными о схемах, пользователях, приложениях и т. д. Системный каталог, который еще называют словарем данных, является, таким образом, хранилищем информации, описывающей данные в базе данных. Предполагается, что каталог доступен как пользователям, так и функциям СУБД. Обычно в словаре данных: содержится следующая информация: • имена, типы и размеры элементов данных; • имена связей; • накладываемые на данные ограничения поддержки целостности; • имена пользователей, которым предоставлено право доступа к данным; • внешняя, концептуальная и внутренняя схемы и отображения между ними; • статистические данные, например частота транзакций и счетчики обращений к объектам базы данных. 7. Поддержка языков БД Для работы с базами данных используются специальные языки, называемые языками баз данных. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language — язык структурированных запросов). Язык SQL позволяет определять схему реляционной БД и манипулировать данными. Исходя из рассмотренных функций, в структуре СУБД в современном представлении можно выделить следующие функциональные блоки: • процессор описания и поддержания структуры базы данных; • процессор запросов к базе данных; • монитор транзакций; • интерфейс ввода данных; • интерфейс запросов; • интерфейс выдачи сведений; • генератор отчетов. Схематично взаимодействие компонент СУБД представлено на рис. 15. Ядром СУБД является процессор описания и поддержания структуры базы данных. Он реализует модель организации данных, средствами которой проектировщик строит логическую структуру (схему) базы данных, соответствующую инфологической схеме предметной области АИС, и обеспечивает построение и поддержание внутренней схемы базы данных. Процессором описания и поддержания структуры данных в терминах используемой модели данных (иерархическая, сетевая, реляционная) обеспечиваются установки заданной логической структуры базы данных, а также трансляция (перевод) структуры базы данных во внутреннюю схему базы данных (в физические структуры данных). В АИС на базе реляционных СУБД процессор описания и поддержания структуры базы данных реализуется на основе языка базы данных, являющегося составной частью языка структурированных запросов (SQL). Рисунок 15 - Структура и взаимодействие компонент СУБД Интерфейс ввода данных СУБД реализует входной информационный язык банка данных, обеспечивая абонентам-поставщикам информации средства описания и ввода данных в информационную систему. Одной из современных тенденций развития СУБД является стремление приблизить входные информационные языки и интерфейс ввода к естественному языку общения с пользователем в целях упрощения эксплуатации информационных систем так называемых «неподготовленными» пользователями. Данная проблема решается через применение диалоговых методов организации интерфейса и использование входных форм. Входные формы, по сути, представляют собой электронные аналоги различного рода анкет, стандартизованных бланков и таблиц, широко используемых в делопроизводстве и интуитивно понятных большинству людей (неподготовленных пользователей). Интерфейс ввода при этом обеспечивает средства создания, хранения входных форм и их интерпретацию в терминах описания логической структуры базы данных для передачи вводимых через формы сведений процессору описания и поддержания структуры базы данных. Интерфейс запросов совместно с процессором запросов обеспечивает концептуальную модель использования информационной системы в части стандартных типовых запросов, отражающих информационные потребности пользователей-абонентов системы. Интерфейс запросов предоставляет пользователю средства выражения своих информационных потребностей. Современной тенденцией развития СУБД является использование диалогово-наглядных средств в виде специальных «конструкторов» или пошаговых «мастеров» формирования запросов. Процессор запросов интерпретирует сформированные запросы в терминах языка манипулирования данными и совместно с процессором описания и поддержания структуры базы данных собственно и исполняет запросы. В реляционных СУБД основу процессора запросов составляет язык манипулирования данными, являющийся основной частью языка SQL. Тем самым на базе процессора запросов и процессора описания и поддержания структуры базы данных образуется низший уровень оперирования данными в СУБД, который иногда называют машиной данных. Стандартные функции и возможности машины данных используют компоненты СУБД более высокого порядка, что позволяет разделить и стандартизировать компоненты СУБД и банка данных на три уровня—логический уровень, машина данных и собственно сами данные. Функции монитора транзакций, как уже отмечалось, заключаются в организации совместного выполнения транзакций от нескольких пользователей над общими данными. При этом дополнительной функцией, неразрывно связанной, в том числе и с основной функцией, является обеспечение целостности данных и ограничений над данными, определяемыми правилами предметной области АИС. Интерфейс выдачи СУБД получает от процессора запросов результаты исполнения запросов (обращений к базе данных) и переводит эти результаты в форму, удобную для восприятия и выдачи пользователю-абоненту информационной системы. Для отображения результатов исполнения запросов в современных СУБД используются различные приемы, позволяющие «визуализировать» данные в привычной и интуитивно понятной неподготовленному пользователю форме. Обычно для этого применяются табличные способы представления структурированных данных, а также специальные формы выдачи данных, представляющие также, как и формы ввода, электронные аналоги различных стандартизованных бланков и отчетов в делопроизводстве. Формы выдачи лежат также и в основе формирования так называемых «отчетов», выдающих результаты поиска и отбора информации из БД в письменной форме для формализованного создания соответствующих текстовых документов, т. е. для документирования выводимых данных. Для подобных целей в состав современных СУБД включаются генераторы отчетов. В заключение по структуре и составу СУБД следует также добавить, что современные программные средства, реализующие те или иные СУБД, представляют собой совокупность инструментальной среды создания и использования баз данных в рамках определенной модели данных (реляционной, сетевой, иерархической или смешанной) и языка СУБД (язык описания данных, язык манипулирования данными, язык и средства создания интерфейса). На основе программных средств СУБД проектировщики строят в целях реализации конкретной информационной системы (инфологическая схема предметной области, задачи и модель использования, категории пользователей и т. д.) автоматизированный банк данных, функционирование которого в дальнейшем поддерживают администраторы системы и услугами которого пользуются абоненты системы. 3.2. Языки баз данных В СУБД поддерживается несколько специализированных по своим функциям подъязыков. Их можно разбить на две категории: • язык определения данных БД — ЯОД (DDL — Data Definition Language); • язык манипулирования данными— ЯМД (DML — Data Manipulation , Language). 3.2.1. Язык определения данных Язык определения данных — описательный язык, с помощью которого описывается предметная область: именуются объекты, определяются их свойства и связи между объектами. Он используется главным образом для определения логической структуры БД. Схема базы данных, выраженная в терминах специального языка определения данных, состоит из набора определений. Язык ЯОД используется как для определения новой схемы, так и для модификации уже существующей. Результатом компиляции ЯОД — операторов является набор таблиц, хранимый в системном каталоге, в котором содержатся метаданные — т. е. данные, которые включают определения записей, элементов данных, а также другие объекты, представляющие интерес для пользователей или необходимые для работы СУБД. Перед доступом к реальным данным СУБД обычно обращается к системному каталогу. 3.2.2. Языки манипулирования данными Язык манипулирования данными содержит набор операторов манипулирования данными, т. е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Множество операций над данными можно классифицировать следующим образом: 1. операции селекции; 2. действия над данными: • включение — ввод экземпляра записи в БД с установкой его связей; • удаление — исключение экземпляра записи из БД с установкой новых связей; • модификация — изменение содержимого экземпляра записи и коррекция связей при необходимости. Языки манипулирования данными делятся на два типа. Это разделение обусловлено коренным различием в подходах к работе с данными, а следовательно, различием в базовых конструкциях в работе с данными. Первый тип — это процедурный ЯМД. Второй тип — это декларативный (непроцедурный) ЯМД. К процедурным языкам манипулирования данными относятся и языки, поддерживающие операции реляционной алгебры, которую основоположник теории реляционных баз данных Э. Ф. Кодд ввел для управления реляционной базой данных. Реляционная алгебра — это процедурный язык обработки реляционных таблиц, где в качестве операндов выступают таблицы в целом. Декларативные языки предоставляют пользователю средства, позволяющие указать лишь то, какие данные требуются. Решение вопроса о том, как их следует извлекать, берет на себя процессор данного языка, работающий с целыми наборами записей. Реляционные СУБД обычно включают поддержку непроцедурных языков манипулирования данными — чаще всего это бывает язык структурированных запросов SQL или язык запросов по образцу QBE. В настоящее время нормой является поддержка декларативного языка SQL, в основе которого лежит реляционное исчисление, также введенное Э Коддом. Этот язык стал стандартом для языков реляционных баз данных, что позволяет использовать один и тот же синтаксис и структуру команд при переходе от одной СУБД к другой Следует отметить, что язык SQL имеет сразу два компонента: язык DDL (ЯОД) для описания структуры базы данных, и язык DML (ЯМД) для выборки и обновления данных. Другим широко используемым языком обработки данных является язык QBE, который заслужил репутацию одного из самых простых способов извлечения информации из базы данных. Особенно это ценно для пользователей, не являющихся профессионалами в этой области Язык предоставляет графические средства создания запросов на выборку данных с использованием шаблонов Ответ на запрос также представляет собой графическую информацию Часть непроцедурного языка ЯМД, которая отвечает за извлечение данных, называется языком запросов Язык запросов можно определить как высокоуровневый узкоспециализированный язык, предназначенный для удовлетворения различных требований по выборке информации из базы данных. 3.2.3. Язык SQL Как следует из рассмотрения внутренней схемы баз данных, одной из основных функций систем управления базами данных является создание и поддержание собственной системы размещения и обмена данными между внешней (дисковой) и оперативной памятью. От эффективности реализации в каждой конкретной СУБД данной функции (формат файлов данных, индексирование, хэширование и буферизация) во многом зависит и эффективность функционирования СУБД в целом. Поэтому основные усилия создателей первых СУБД в конце 60-х — начале 70-х годов были сосредоточены именно в этом направлении. Однако такой подход приводил к «самостийности», уникальности каждой конкретной СУБД и созданной на ее основе автоматизированной информационной системы. В результате для реализации любой функции по вводу, обработке или выводу данных требовались квалифицированные программисты для написания специальных программ на алгоритмических языках высокого уровня (в 70-х годах ФОРТРАН, КОБОЛ и др.), «знающих» особенности структуры и способы размещения данных во внешней и оперативной памяти. В итоге работа с базами данных осуществлялась через посредника в виде квалифицированного программиста, «переводящего» информационные потребности пользователя в машинный код, что схематично иллюстрируется на рис. 16. Рисунок 16 - Схема взаимодействия пользователя с базой данных в ранних СУБД Такое положение дел приводило к большим накладным расходам при создании и эксплуатации автоматизированных информационных систем и в определенной степени сдерживало распространение вычислительной техники в процессах информационного обеспечения деятельности предприятий и организаций. Основателем теории реляционных СУБД Коддом было выдвинуто предложение о создании специального языка для общения (взаимодействия) пользователя-непрограммиста с базами данных. Идея такого языка сводилась к набору из нескольких фраз-примитивов английского языка («выбрать», «обновить», «вставить», «удалить»), через которые пользователь-непрограммист ставил бы «вопросы» к СУБД по своим информационным потребностям. В этом случае дополнительной функцией СУБД должна быть интерпретация этих «вопросов» на низкоуровневый язык машинных кодов для непосредственной обработки данных и предоставление результатов пользователю. Так родилась уже упоминавшаяся по структуре СУБД «машина данных». Иначе говоря, машина данных «понимает» язык базы данных и в результате разделяет собственно данные и задачи по их обработке. В таком подходе взаимодействие пользователя с базой данных можно проиллюстрировать схемой, приведенной на рис. 17. Рисунок 17 - Схема взаимодействия пользователя с базой данных через язык баз данных В практику эти идеи впервые претворились в ходе реализации проекта System R (1975-1979 гг.) с участием еще одного известного специалиста по базам данных Криса Дейта. В ходе проекта System R был создан язык SEQUEL, трансформировавшийся впоследствии в язык структурированных запросов SQL (Structured Query Language). При этом дополнительно к возможностям формирования «вопросов» к базе данных пользователю также решено было предоставить и возможность описания самой структуры данных, ввода данных и их изменения. Идеи языка SQL оказались настолько плодотворными, что он быстро завоевал популярность и стал широко внедряться в создаваемых в конце 70-х и в 80-х годах реляционных СУБД. Однако плодотворность идей языка SQL в отличие от первоначального замысла проявилась вовсе не в том, что на нем стали «разговаривать» с базами данных пользователи, не являющиеся профессиональными программистами. Язык SQL, в конечном счете, позволил, как уже отмечалось, отделить низкоуровневые функции по организации структуры и обработке данных от высокоуровневых функций, позволяя при создании и эксплуатации банков данных сосредоточиваться на смысловом, а не техническом аспекте работы с данными. Быстрое и массовое распространение языка SQL в реляционных СУБД к середине 80-х годов привело фактически к принятию его в качестве стандарта по организации и обработке данных. В 1986 г. Американским национальным институтом стандартов (ANSI) и Международной организацией по стандартизации (ISO) язык был стандартизирован де-юре, т. е. признан стандартным языком описания и обработки данных в реляционных СУБД. В1989 г. ANSI/ISO была принята усовершенствованная версия SQL — SQL2, а в 1992 г. третья версия — SQL3. Язык SQL относится к так называемым декларативным (непроцедурным) языкам программирования. В отличие от процедурных языков (С, Паскаль, Фортран, Кобол, Бейсик) на нем формулируются предложения (инструкции) о том, «что сделать», но не «как сделать, как получить». Машина данных в СУБД исполняет роль интерпретатора и как раз строит машинный код, реализующий способ получения результата, задаваемого SQL-инструкциями. Язык SQL состоит из двух частей: • языка описания (определения) данных — DDL (Data Definition Language); • языка манипулирования данными — DML (Data Manipulation Language). Синтаксис SQL-инструкций включает: • название инструкции (команду); • предложения, определяющие источники, условия операции; • предикаты, определяющие способы и режимы отбора записей, задаваемых предложениями; • выражения, значения которых задают свойства и параметры выполнения инструкции и предложения. Структуру SQL-инструкций можно разделить на две основные части, схематично представленные на рис. 18. Рисунок 18 - Структура SQL-инструкций Первая часть включает название (команду) SQL-инструкции, предикат (необязательный элемент) и аргументы инструкции, которыми являются перечисляемые через запятую имена полей одной или нескольких таблиц. Вторая часть состоит из одного или нескольких предложений, аргументы которых могут задавать источники данных (имена таблиц, операции над таблицами), способы, условия и режимы выполнения команды (предикаты сравнения, логические и математические выражения по значениям полей таблиц). Выражениями в инструкциях SQL являются любые комбинации операторов, констант, значений текстовых констант, функций, имен полей, построенные по правилам математических выражений и результатом которых является конкретное, в том числе и логическое значение. Язык SQL, конечно же, сточки зрения профессиональных программистов построен довольно просто, но, вместе с тем, как уже отмечалось, надежды на то, что на нем станут общаться с базами данных пользователи-непрограммисты, не оправдались. Причина этого, вероятно, заключается в том, что, несмотря на простоту, язык SQL все же является формализованным искусственным языком, осваивание и использование которого в большинстве случаев тяготит конечных пользователей. Исследования основ и способов интерфейса человека с компьютером, эргономических и психологических основ работы с компьютерной информацией, проведенные в конце 70-х и в 80-х годах, показали, что пользователи-специалисты в конкретных предметных областях (а не в области вычислительной техники и программирования) более склонны к диалогово-визуальным формам работы с вычислительными системами и компьютерной информацией. Поэтому с конца 80-х годов в развитии СУБД наметились две тенденции: • СУБД для конечных пользователей; • СУБД для программистов (профессионалов). В СУБД для конечных пользователей имеется развитый набор диалоговых и визуально-наглядных средств работы с базой данных в виде специальных диалоговых интерфейсов и пошаговых «мастеров», которые «ведут» пользователя по пути выражения им своих потребностей в обработке данных. Например, при создании новой таблицы соответствующий «мастер» последовательно запрашивает у пользователя имя таблицы, имена, типы и другие параметры полей, индексов и т. д. При этом интерфейсная часть СУБД формирует для ядра СУБД (машины данных) соответствующую и порой весьма сложную инструкцию SQL. В профессиональных СУБД язык базы данных (SQL) дополняется элементами, присущими процедурным языкам программирования — описателями и средствами работы с различного типа переменными, операторами, функциями, процедурами и т. д. В результате формируется специализированный на работу с данными декларативно-процедурный язык высокого уровня, который встроен в СУБД (точнее надстроен над ядром СУБД). Такие языки называют «включающими». На основе включающего языка разрабатываются полностью автономные прикладные информационные системы, реализующие более простой и понятный для специалистов в определенной предметной области (скажем, в бухгалтерии) интерфейс работы с информацией. С учетом этапов в развитии программных средств СУБД такие языки получили название языков четвертого поколения —4GL (Forth Generation Language). Языки 4GL могут быть непосредственно встроены в сами СУБД, а могут существовать в виде отдельных сред программирования. В последнем случае в таких средах разрабатываются прикладные части информационных систем, реализующие только интерфейс и высокоуровневые функции по обработке данных. За низкоуровневым, как говорят, «сервисом» к данным такие прикладные системы обращаются к SQL-серверам, являющимися отдельными специализированными разновидностями СУБД. «Общение» между прикладными системами и SQL-серверами происходит соответственно на языке SQL. 3.3. Трехуровневая архитектура СУБД Одним из важнейших аспектов развития СУБД является идея отделения логической структуры БД и манипуляций данными, необходимыми пользователям, от физического представления, требуемого компьютерным оборудованием. Одна и та же БД в зависимости от точки зрения может иметь различные уровни описания. По числу уровней описания данных, поддерживаемых СУБД, различают одно-, двух- и трехуровневые системы. В настоящее время чаще всего поддерживается трехуровневая архитектура описания БД (рис. 19), с тремя уровнями абстракции, на которых можно рассматривать базу данных. Рисунок 19 - Трехуровневая архитектура СУБД Такая архитектура включает: • внешний уровень, на котором пользователи воспринимают данные, где отдельные группы пользователей имеют свое представление (ПП) на базу данных; • внутренний уровень, на котором СУБД и операционная система воспринимают данные; • концептуальный уровень представления данных, предназначенный для отображения внешнего уровня на внутренний уровень, а также для обеспечения необходимой их независимости друг от друга; он связан с обобщенным представлением пользователей. Описание структуры данных на любом уровне называется схемой. Существует три различных типа схем базы данных, которые определяются в соответствии с уровнями абстракции трехуровневой архитектуры. На самом высоком уровне имеется несколько внешних схем или подсхем, которые соответствуют разным представлениям данных. На концептуальном уровне описание базы данных называют концептуальной схемой, а на самом низком уровне абстракции — внутренней схемой. Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. Суть этой независимости заключается в том, что изменения на нижних уровнях никак не влияют на верхние уровни. Различают два типа независимости от данных: логическую и физическую. Логическая независимость от данных означает полную защищенность внешних схем от изменений, вносимых в концептуальную схему. Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы для других групп пользователей. Физическая независимость от данных означает защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему. Такие изменения внутренней схемы, как использование различных файловых систем или структур хранения, разных устройств хранения, модификация индексов или хеширование, должны осуществляться без необходимости внесения изменений в концептуальную или внешнюю схемы. Далее рассмотрим каждый из трех названных уровней. Внешний уровень — это пользовательский уровень. Пользователем может быть программист, или конечный пользователь, или администратор базы данных. Представление базы данных с точки зрения пользователей называется внешним представлением. Каждая группа пользователей выделяет в моделируемой предметной области, общей для всей организации, те сущности, атрибуты и связи, которые ей интересны. Эти частичные или переопределенные описания БД для отдельных групп пользователей или ориентированные на отдельные аспекты предметной области называют подсхемой. Концептуальный уровень является промежуточным уровнем в трехуровневой архитектуре и обеспечивает представление всей информации базы данных в абстрактной форме. Описание базы данных на этом уровне называется концептуальной схемой, которая является результатом концептуального проектирования. Концептуальное проектирование базы данных включает анализ информационных потребностей пользователей и определение нужных им элементов данных. Таким образом, концептуальная схема — это единое логическое описание всех элементов данных и отношений между ними, логическая структура всей базы данных. Для каждой базы данных имеется только одна концептуальная схема. Концептуальная схема должна содержать: • сущности и их атрибуты; • связи между сущностями; • ограничения, накладываемые на данные; • семантическую информацию о данных; • обеспечение безопасности и поддержки целостности данных. Внутренний уровень является третьим уровнем архитектуры БД. Внутренняя схема описывает физическую реализацию базы данных и предназначена для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. Для каждой базы данных существует только одна внутренняя схема. На внутреннем уровне хранится следующая информация: • распределение дискового пространства для хранения данных и индексов; • описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных); • сведения о размещении записей; • сведения о сжатии данных и выбранных методах их шифрования. СУБД отвечает за установление соответствия между всеми тремя типами схем разных уровней, а также за проверку их непротиворечивости. Ниже внутреннего уровня находится физический уровень, который контролируется операционной системой, но под руководством СУБД. Физический уровень учитывает, каким образом данные будут представлены в машине. Он обеспечивает физический взгляд на базу данных: дисководы, физические адреса, индексы, указатели и т. д. За этот уровень отвечают проектировщики физической базы данных, которые работают только с известными операционной системе элементами. Область их интересов: указатели, реализация последовательного распределения, способы хранения полей внутренних записей на диске. Однако функции СУБД и операционной системы на физическом уровне не вполне четко разделены и могут варьироваться от системы к системе. 4. Основы создания автоматизированных информационных систем 4.1. Общие положения по созданию автоматизированных систем Создание автоматизированных информационных систем в нашей стране регламентируется «Комплексом стандартов и руководящих документов на автоматизированные системы» (ГОСТ 34.201-89, ГОСТ 34.602-89, РД 50-682, РД 50-680-88, ГОСТ 34.601-90, ГОСТ 34.401-90, РД 50-34.698-90, ГОСТ 34.003-90, Р 50-34.119-90). В частности, ГОСТ 34.601-90 определяет следующие стадии и этапы создания АИС (см. табл. 3). Таблица 3 – Этапы и стадии создания АИС Этап Стадии 1. Формирование требований к АИС 1.1. Обследование объекта и обоснование необходимости создания АИС 1.2. Формирование требований пользователя к АИС 1.3. Оформление отчета о выполненной работе и заявки на разработку АИС (тактико-технического задания) 2. Разработка концепции АИС 2.1. Изучение объекта 2.2. Проведение необходимых научно-исследовательских работ 2.3. Разработка вариантов концепции АИС и выбор варианта концепции АИС, удовлетворяющего требованиям пользователя 2.4. Оформление отчета о выполненной работе 3. Техническое задание 3.1. Разработка и утверждение технического задания на создание АИС 4. Эскизный проект 4.1. Разработка предварительных проектных решений по системе и ее частям 4.2. Разработка документации на АИС и ее части 5. Технический проект 5.1. Разработка проектных решений по системе и ее частям 5.2. Разработка документации на АИС и ее части 5.3. Разработка и оформление документации на поставку изделий для комплектования АИС и (или) технических требований (технических заданий) на их разработку 5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации 6. Рабочая документация 6.1. Разработка рабочей документации на систему и ее части 6.2. Разработка или адаптация программ 7. Ввод в действие 7.1. Подготовка объекта автоматизации к вводу АИС в действие 7.2. Подготовка персонала 7.3. Комплектация АИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями) 7.4. Строительно-монтажные работы 7.5. Пусконаладочные работы 7.6. Проведение предварительных испытаний 7.7. Проведение опытной эксплуатации 7.8. Проведение приемочных испытаний 8. Сопровождение АИС 8.1. Выполнение работ в соответствии с гарантийными обязательствами 8.2. Послегарантийное обслуживание Одним из центральных элементов всего процесса создания АС является разработка технического задания, структура которого согласно ГОСТ 34.602-89 содержит следующие разделы: 1) общие сведения; 2) назначение и цели создания (развития) системы; 3) характеристика объектов автоматизации; 4) требования к системе; 5) состав и содержание работ по созданию системы; 6) порядок контроля и приемки системы; 1) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; 7) требования к документированию; 8) источники разработки. Суть технического задания как основного документа в процессе создания АИС заключается в проработке, выборе и утверждении основных технических, организационных, программных, информационно-логических и лингвистических решений, которые устанавливаются в разделе «Требования к системе». Данный раздел, в свою очередь, состоит из трех подразделов: 1) требования к системе в целом; 1) требования к функциям (задачам), выполняемым системой; 2) требования к видам обеспечения. Требования к системе в целом отражают концептуальные параметры и характеристики создаваемой системы, среди которых указываются требования к структуре и функционированию системы, к надежности и безопасности, к численности и квалификации персонала и т. д. Требования к функциям (задачам) содержат перечень функций, задач или их комплексов; временной регламент каждой функции, задачи или комплекса задач; требования к качеству реализации каждой функции; к форме представления выходной информации; характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций; достоверности выдачи результатов. Требования по видам обеспечения в зависимости от вида системы содержат требования по математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другим видам обеспечения системы. Для большинства разновидностей АИС, в частности для всевозможных видов АИС, особое значение имеют решения и требования по информационному обеспечению. В данном подразделе, в частности, определяются требования: • к составу, структуре и способам организации данных в системе (информационно-логическая схема); • к информационному обмену между компонентами системы; • к информационной совместимости со смежными системами; • по использованию общероссийских и других классификаторов, унифицированных документов; • по применению систем управления базами данных; • к структуре процесса сбора, обработки, передачи данных в системе и представлению данных; • к защите данных от разрушений при авариях и сбоях в электропитании системы; • к контролю, хранению, обновлению и восстановлению данных; • к процедуре придания юридической силы документам, продуцируемым техническими средствами АИС. На основе установленных в техническом задании основных требований и технических решений на последующих этапах конкретизируются и непосредственно разрабатываются компоненты и элементы системы. В частности, на этапе 4.1 «Разработка предварительных проектных решений по системе и ее частям» определяются: • функции АИС; • функции подсистем; • концепция информационной базы и ее укрупненная структура; • функции системы управления базой данных; • состав вычислительной системы; • функции и параметры основных программных средств. На этапе 5.1 «Разработка проектных решений по системе и ее частям» осуществляется разработка общих решений по системе и ее частям: • по функционально-алгоритмической структуре системы; • по функциям персонала и организационной структуре; • по структуре технических средств; • по алгоритмам решения задач и применяемым языкам; • по организации и ведению информационной базы (структура базы данных); • по системе классификации и кодирования информации (словарно-классификационная база); • по программному обеспечению. Разработка и документация программного обеспечения в процессе создания или комплектования автоматизированных систем (п. 6.2) регламентируются комплексом стандартов, объединенных в группу «Единая система программной документации (ЕСПД)». Таким образом, создание автоматизированных информационных систем представляет собой сложный многоэтапный процесс, требующий привлечения различных категорий специалистов — программистов, инженеров, управленческих и других работников. 4.2. Жизненный цикл БД АИС Одной из наиболее трудоемких и сложных задач при создании АИС является проектирование банка данных как основы подсистемы представления и обработки информации. Логическая и физическая структуры банка данных отражают представление разработчиками и пользователями информационной системы той предметной области, сведения о которой предполагается отражать и использовать в АИС. Как и любой программный продукт, база данных автоматизированной информационной системы обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы. ЖЦБД включает в себя следующие основные этапы: 1. планирование разработки базы данных; 2. определение требований к системе; 3. сбор и анализ требований пользователей; 4. проектирование базы данных: • системный анализ предметной области; • инфологическое проектирование; • выбор СУБД; • даталогическое проектирование; • физическое проектирование. 5. разработка приложений: • проектирование транзакций; • проектирование пользовательского интерфейса; 6. реализация; 7. загрузка данных; 8. тестирование; 9. эксплуатация и сопровождение. 4.3. Архитектура и проектирование информационных систем 4.3.1. Стили проектирования ИС Архитектурное описание самым тесным образом связано с про­цессом проектирования ИС, причем в ряде определений термина «архитектура» на этот факт указывается в явном виде. Обычно вы­деляются пять различных подходов к проектированию, которые на­зывают также стилями проектирования и, по существу, определяют группы методологий разработки ПО: • календарный стиль — основанный на календарном планирова­нии (Calendar-driven); • стиль, основанный на управлении требованиями (Requirements- driven); • стиль, в основу которого положен процесс разработки докумен­тации (Documentation-driven); • стиль, основанный на управлении качеством (Quality-driven); • архитектурный стиль (Architecture-driven). Основой календарного стиля является график работ. Команда разработчиков выполняет работы поэтапно. Проектные решения принимаются из целей и задач конкретного этапа. Слабыми места­ми данного стиля являются то, что основные решения принимаются исходя из локальных целей, при этом мало внимания уделяется про­цессу разработки, разработке документации, созданию стабильных архитектур и внесению изменений. Все это приводит к высокой сум­марной стоимости владением в долгосрочном плане. Данный стиль считается морально устаревшим, однако многие организации про­должают его использовать. Стиль, основанный на управлении требованиями, предполага­ет, что основное внимание уделяется функциональным характери­стикам системы, при этом часто недостаточно внимания уделяется нефункциональным характеристикам, таким как масштабируемость, портабельность, поддерживаемость и другим, определенным в ISO 9126. Проектные решения принимаются преимущественно исходя из локальных целей, связанных с реализацией тех или иных функций. Данный подход достаточно эффективен в случае, если требования определены и не изменяются в процессе проектирования. Основные недостатки данного подхода следующие: недостаточное внимание уделяется требованиям стандарта ISO 9126 (управление качеством); разрабатываемые архитектуры, как правило, не являются стабильны­ми, так как каждая из реализуемых функций отображается на один или несколько функциональных компонентов. Это обстоятельство усложняет добавление к системе новых требований. Данный под­ход позволяет успешно отслеживать требования в плане реализации требуемой функциональности, однако использование его для долго­срочных проектов является неэффективным. Стиль, в основу которого положен процесс разработки до­кументации, до настоящего времени продолжает использоваться в правительственных организациях и крупных компаниях. Данный стиль может рассматриваться как вырожденный вариант стиля, осно­ванного на управлении качеством, и ориентирован на разработку документации. В качестве основных недостатков данного подхода выделяются следующие: неоправданно много времени и сил затра­чивается на разработку документации в ущерб качеству разрабаты­ваемого кода. При этом создаваемая документация часто не исполь­зуется ни пользователем, ни заказчиком. Стиль, основанный на управлении качеством, предполагает са­мое широкое использование различных мер для отслеживания кри­тичных с точки зрения функционирования параметров. Например, требуется получить время реакции системы на запрос менее одной секунды или обеспечить среднее время между отказами не менее 10 лет. В этом случае данные параметры отслеживаются на всех этапах проектирования систем и часто это делается в ущерб другим харак­теристикам, таким как масштабируемость, простота сопровождения и т. п. Типовыми проблемами, возникающими при использовании данного стиля, являются следующие: часто оптимизируются не те параметры, которые должны быть в действительности, когда по­являются новые требования, бывает очень трудно изменить функ­циональность системы. Созданные таким образом системы обычно не отличаются высоким качеством архитектурных решений. В целом данный стиль считается консервативным. Его использование может быть оправдано в случае, когда необходимо создать системы с экс­тремальными характеристиками. Архитектурный стиль представляет собой наиболее зрелый под­ход к проектированию. В рамках данного стиля во главу угла ставит­ся создание фреймворков, которые могут быть легко адаптированы ко всем потенциальным требованиям всех потенциальных заказчи­ком. Отличительная особенность данного стиля состоит в том, что задача проектирования разбивается на две отдельные подзадачи: создание многократно используемого фреймворка и создание кон­кретного приложения (системы) на его основе. При этом эти две задачи могут решать разные специалисты. Основная цель создания данного стиля — это устранение недостатков стиля, основанного на управлении требованиями. Использование архитектурного сти­ля позволяет реализовать инкрементное и итеративное проектиро­вание, т.е. оперативно изменять существующую и добавлять новую функциональность. 4.3.2. Качество ИС В процессе проектирования важное значение приобретают атри­буты качества ИС. Понятие качества ИС соответствует понятию о том, что система успешно справляется со всеми возлагаемыми на нее задачами, имеет хорошие показатели надежности и приемлемую стоимость, удобна в эксплуатации и обслуживании, легко сочетается с другими систе­мами и в случае необходимости может быть модифицирована. Разные группы пользователей имеют различные точки зрения на характеристики качества ИС. Например, если задать вопрос о том, какой должна быть хорошая ИС, то от пользователя можно получить следующие варианты ответов: • система имеет хорошую производительность; • система имеет широкие функциональные возможности; • система удобна в эксплуатации; • система надежна. Менеджер даст скорее всего другие варианты ответов: • стоимость системы не должна быть изначально очень высокой; • система не должна быть очень дорогой в эксплуатации; • система не должна морально устаревать в течение возможно бо­лее длительного периода времени и в случае необходимости может быть легко модифицирована. Для системного администратора наиболее важными могут ока­заться такие характеристики системы, как • надежность и стабильность работы; • простота администрирования; • наличие хорошей эксплуатационной документации; • хорошая поддержка изготовителем. Другие заинтересованные лица могут иметь свои точки зрения на то, какой должна бьггь качественная система. Поскольку в современных ИС ключевой компонентой является программная компонента, а пользователи, работающие с системой, в большинстве случаев взаимодействуют непосредственно с про­граммной компонентой, поэтому показатели качества информаци­онных и программных систем в значительной степени совпадают. Для того чтобы построить правильную и надежную архитектуру и грамотно спроектировать интеграцию программных систем, не­обходимо четко следовать современным стандартам в этих областях. Без этого велика вероятность создать архитектуру, которая неспо­собна развиваться и удовлетворять растущие потребности пользо­вателей ИТ. В качестве законодателей стандартов в этой области выступают такие международные организации, как SEI (Software Engineering Institute), WWW (консорциум World Wide Web), OMG (Object Management Group), организация разработчиков Java — JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) и др. Качество программного обеспечения определяется стандартом ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц. Различаются понятия внутреннего качества, связанного с характе­ристиками программного обеспечения (ПО) самого по себе, без уче­та его поведения; внешнего качества, характеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах — того качества, которое ощущается пользователями при конкретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для созда­ния добротного ПО существенное значение имеет качество техноло­гических процессов его разработки. ISO 9126 — это международный стандарт, определяющий оценоч­ные характеристики качества программного обеспечения. Россий­ский аналог стандарта ГОСТ 28195. Стандарт разделяется на четыре части, описывающие следующие вопросы: модель качества, внешние метрики качества, внутренние метрики качества, метрики качества в использовании. Вторая и третья части стандарта ISO 9126-2,3 посвящены форма­лизации соответственно внешних и внутренних метрик характери­стик качества сложных программных систем. В ней изложены содержание и общие рекомендации по использованию соответствующих метрик и взаимосвязей между типами метрик. Четвертая часть стандарта ISO 9126-4 предназначена для покупа­телей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества ПС. В ней повторена концепция трех типов метрик, а также аннотированы рекомендуемые виды измерений ха­рактеристик. Модель качества, установленная в первой части стандарта ISO 9126-1, классифицирует качество ПО в шести структурных наборах характеристик: • функциональность; • надежность; • производительность (эффективность); • удобство использования (практичность); • удобство сопровождения; • переносимость. Перечисленные характеристики, в свою очередь, детализированы подхарактеристиками (субхарактеристиками) (рис. 20). Ниже при­ведены определения этих характеристик и атрибутов по стандарту ISO 9126:2001. Функциональность (functionality) определяется как способность ПО в определенных условиях решать задачи, нужные пользователям. Для данной характеристики выделяются следующие субхаракте­ристики: • функциональная пригодность; • точность; • способность к взаимодействию; • защищенность; • соответствие стандартам и правилам. Функциональная пригодность (suitability) определяется как спо­собность решать нужный набор задач. Точность (accuracy) — определяется как способность выдавать нужные результаты. Способность к взаимодействию (interoperability) — способность взаимодействовать с нужным набором других систем. Соответствие стандартам и правилам (compliance) — соот­ветствие ПО имеющимся отраслевым стандартам, нормативным и за­конодательным актам, другим регулирующим нормам. Рисунок 20 – Характеристики качества ИС Защищенность (security) — способность предотвращать неавтори- зированный, т.е. без указания лица, пытающегося его осуществить, и неразрешенный доступ к данным и программам. Надежность (reliability) — способность ПО поддерживать опре­деленную работоспособность в заданных условиях. Для данной характеристики выделяются следующие субхаракте­ристики: • зрелость (завершенность); • устойчивость к отказам; • способность к восстановлению; • соответствие стандартам надежности (reliability compliance). Зрелость, завершенность (maturity) — величина, обратная ча­стоте отказов ПО. Обычно измеряется средним временем работы без сбоев и величиной, обратной вероятности возникновения отказа за данный период времени. Устойчивость к отказам (fault tolerance) — способность под­держивать заданный уровень работоспособности при отказах и на­рушениях правил взаимодействия с окружением. Способность к восстановлению (recoverability) определяется как способность восстанавливать определенный уровень работоспособ­ности и целостность данных после отказа, необходимые для этого время и ресурсы. Производительность (efficiency), или эффективность, — спо­собность ПО при заданных условиях обеспечивать необходимую ра­ботоспособность по отношению к выделяемым для этого ресурсам. Можно определить ее и как отношение получаемых с помощью ПО результатов к затрачиваемым на это ресурсам всех типов. Для данной характеристики выделяются следующие субхаракте­ристики: • временная эффективность; • эффективность использования ресурсов; • соответствие стандартам производительности (efficiency compli­ance). Временная эффективность (time behaviour) — способность ПО выдавать ожидаемые результаты, а также обеспечивать передачу не­обходимого объема данных за отведенное время. Эффективность использования ресурсов (resource utilisation) — способность решать нужные задачи с использованием определенных объемов ресурсов определенных видов. Имеются в виду такие ресур­сы, как оперативная и долговременная память, сетевые соединения, устройства ввода и вывода и пр. Удобство использования (usability), или практичность, опреде­ляется как способность ПО быть удобным в обучении и использова­нии, а также привлекательным для пользователей. Для данной характеристики выделяются следующие субхаракте­ристики: • понятность; • удобство работы; • удобство обучения; • привлекательность; • соответствие стандартам удобства использования (usability com­pliance). Понятность (understandability) — это показатель, обратный уси­лиям, которые затрачиваются пользователями на восприятие основ­ных понятий ПО и осознание их применимости для решения своих задач. Удобство работы (operability) — это показатель, обратный уси­лиям, предпринимаемым пользователями для решения своих задач с помощью ПО. Удобство обучения (learnability) — показатель, обратный усилиям, затрачиваемым пользователями на обучение работе с ПО. Привлекательность (attractiveness) — это способность ПО быть привлекательным для пользователей. Этот атрибут добавлен в 2001 г. Удобство сопровождения (maintainability) определяется как удобство проведения всех видов деятельности, связанных с сопро­вождением программ. Для данной характеристики выделяются следующие субхаракте­ристики: • анализируемость; • удобство внесения изменений; • стабильность; • удобство проверки; • соответствие стандартам удобства сопровождения (maintainability compliance). Анализируемость (analyzability), или удобство проведения анали­за, определяется как удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа необходимости изменений и их возможных последствий. Удобство внесения изменений (changeability) — показатель, об­ратный трудозатратам на выполнение необходимых изменений. Стабильность (stability) — показатель, обратный риску возник­новения неожиданных эффектов при внесении необходимых изме­нений. Удобство проверки (testability) — показатель, обратный трудоза­тратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным результатам. Переносимость (portability) определяется как способность ПО сохранять работоспособность при переносе из одного окружения в другое, включая организационные, аппаратные и программные аспекты окружения. Иногда эта характеристика называется в русскоязычной литера­туре мобильностью. Однако термин «мобильность» стоит зарезерви­ровать для перевода «mobility» — способности ПО и компьютерной системы в целом сохранять работоспособность при ее физическом перемещении в пространстве. Для данной характеристики выделяются следующие субхаракте­ристики: • адаптируемость; • удобство установки; • способность к сосуществованию; • удобство замены; • соответствие стандартам переносимости (portability compli­ance). Адаптируемость (adaptability) — способность ПО приспосабли­ваться к различным окружениям без проведения для этого действий помимо заранее предусмотренных. Удобство установки (installability) — способность ПО быть уста­новленным или развернутым в определенном окружении. Способность к сосуществованию (coexistence) — способность ПО сосуществовать с другими программами в общем окружении, деля с ними ресурсы. Удобство замены (replaceability) другого ПО данным определя­ется как возможность применения данного ПО вместо других про­граммных систем для решения тех же задач в определенном окру­жении. Перечисленные атрибуты относятся к внутреннему и внешнему качеству ПО согласно ISO 9126. Для описания качества ПО при ис­пользовании стандарт ISO 9126-4 предлагает другой, более узкий на­бор характеристик: • эффективность; • продуктивность; • безопасность; • удовлетворение пользователей. Эффективность (effectiveness) — способность ПО предоставлять пользователям возможность решать их задачи с необходимой точно­стью при использовании в заданном контексте. Продуктивность (productivity) — способность ПО предоставлять пользователям определенные результаты в рамках ожидаемых затрат ресурсов. Безопасность (safety) — способность ПО обеспечивать необхо­димо низкий уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности или окружающей среде. Удовлетворение пользователей (satisfaction) — способность ПО приносить удовлетворение пользователям при использовании в за­данном контексте. 4.4 Системный анализ предметной области С точки зрения проектирования БД в рамках системного анализа, необходимо осуществить первый этап, то есть провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области. В общем случае существуют два подхода к выбору состава и структуры предметной области: Функциональный подход - он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны. Предметный подход - когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной. Чаще всего на практике рекомендуется использовать некоторый компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи или функциональные потребности пользователей, а с другой стороны, учитывает возможность наращивания новых приложений. Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД. 4.5 Инфологическое (семантическое) моделирование предметной области Инфологическое моделирование (иногда используется термин семантическое моделирование) применяется на втором этапе проектирования БД, то есть после системного анализа предметной области. На этапе системного анализа были сформированы понятия о предметах, фактах и событиях, которыми будет оперировать БД. Инфологическое проектирование связано с представлением семантики предметной области в модели БД, т.е. моделирование структур данных, опираясь на смысл этих данных. Инфологическое моделирование было предметом исследований в конце 1970-х и начале 1980-х годов. Было предложено несколько моделей данных, названных семантическими моделями. Наибольшее распространение получила модель "сущность-связь" (entity-relationship model, ER-модель), предложенная в 1976 г. Питером Пин-Шэн Ченом. Модель «сущность-связь» является концептуальной моделью, т.е. не учитывает особенности конкретной СУБД. Из модели "сущность-связь" могут быть получены все основные фактографические модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная). Модели "сущность-связь" удобны тем, что процесс создания модели является итерационным. Разработав первый приближенный вариант модели, можно уточнять ее, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, является сама модель "сущность-связь". 4.5.1 Модель «сущность-связь» Основными понятиями модели "сущность-связь" являются: сущность, связь и атрибут. Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться в проектируемой системе. Сущность имеет имя, уникальное в пределах системы. Сущность соответствует некоторому классу однотипных объектов, то есть в системе существует множество экземпляров данной сущности. Примеры сущностей: люди, продукты, студенты и т.д. Примеры экземпляров сущностей: конкретный человек, конкретный продукт, конкретный студент и т. д. Сущности не обязательно должны быть непересекающимися. Например, экземпляр сущности СТУДЕНТ, также принадлежит сущности ЛЮДИ. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов -характеристик, определяющих свойства данного объекта. Атрибут должен иметь имя, уникальное в пределах данной сущности. Пример: Рассмотрим множество пищевых продуктов, имеющихся в магазине. Каждый продукт можно представить следующими характеристиками: Код продукта, Продукт, Срок хранения, Условия хранения. В дальнейшем для определения сущности и ее атрибутов будем использовать обозначение вида: Продукты(КодПродукта, Продукт, ЕдиницаИзмерения, СрокХранения, УсловияХранения). Например, поставщиков, поставляющих продукты в магазин, можно описать как: Поставщики(КодПоставщика, Поставщик, Адрес) Множество допустимых значений (область определения) атрибута называется доменом. Например, атрибут СрокХранения хранит информацию о количестве дней, в течение которых продукт годен к употреблению. То есть этот атрибут принадлежит домену КоличествоДней, который задается интервалом целых чисел больших нуля, поскольку количество дней отрицательным быть не может. Набор атрибутов сущности должен быть таким, чтобы можно было однозначно найти требуемый экземпляр сущности. Например, сущность Продукты однозначно определяется атрибутом КодПродукта, поскольку все коды продуктов различны. Отсюда определяется ключ сущности - это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Пример. Сущность Продажа с атрибутами ДатаПродажи, КодПродукта, Количество, Цена содержит информацию о продаже продуктов за конкретный день. Для этой сущности ключом будут атрибуты ДатаПродажи и КодПродукта, поскольку за день могут быть проданы несколько продуктов, а конкретный продукт может быть продан в разные дни. Исключение любого атрибута из ключа не позволит однозначно найти требуемый экземпляр сущности, т.е. будет нарушено условие минимальности. Обозначим эту сущность как: Продажа(ДатаПродажи. КодПродукта. Количество, Цена) Ключевой атрибут выделен подчеркиванием Между сущностями могут быть установлены связи. Связь - это ассоциация, установленная между несколькими сущностями, и показывающая как взаимодействуют сущности между собой. Примеры: • в магазине происходит продажа продуктов. т.е. между сущностями Продукты и Продажа существует связь «происходит» или Продукты-Продажа (обычно связь обозначается глаголом или двойным названием сущностей. между которыми установлена эта связь) • так как продукты в магазин поставляют поставщики, то между сущностями Продуты и Поставщики существует связь «поставка» или Продукты-Поставщики • могут существовать и связи между экземплярами одной и той же сущности (рекурсивная связь). Например, связь Родитель-Потомок между экземплярами сущности Человек Связь также может иметь атрибуты. Например, для связи Продукты-Поставщики можно задать атрибуты ДатаПоставки. Цена и т.д. Связь. существующая между двумя сущностями. называется бинарной связью. Связь. существующая между n сущностями. называется n-арной связью. Рекурсивная связь - это связь между экземплярами одной сущности. Доказано. что любую n-арную связь всегда можно заменить множеством бинарных. однако первые лучше отображают семантику предметной области. То число экземпляров сущностей. которое может быть ассоциировано через связь с экземплярами другой сущности. называют степенью связи. Рассмотрение степеней особенно полезно для бинарных связей. Очень важным свойством модели "сущность-связь" является то. что она может быть представлена в виде графической схемы (диаграммы). Это значительно облегчает анализ предметной области. Существует несколько вариантов обозначения элементов диаграммы "сущность-связь" (нотаций). Для обозначения сущностей. связей и атрибутов будем использовать нотацию Чена. В Таблице 4 приводится список используемых здесь обозначений. Таблица 4 – Список обозначений по нотации Чена 4.5.2 Степени бинарных связей • один-к-одному (обозначается 1:1). Это означает, что в такой связи в каждый момент времени каждому экземпляру сущности A соответствует 1 или 0 экземпляров сущности B. Данный факт представлен на Рис. 21, где прямоугольники обозначают сущности, а ромб - связь. Так как степень связи для каждой сущности равна 1, то они соединяются одной линией. Рисунок 21 – Связь один-к-одному один-ко-многим (1:N). Одному экземпляру сущности A соответствуют 0, 1 или N экземпляров сущности B. Графически степень связи N отображается "древообразной" линией, так это сделано на следующем рисунке (Рис. 22). Рисунок 22 – Связь один-ко-многим многие-к-одному (N:1). Эта связь аналогична отображению 1:N. Одному экземпляру сущности В соответствуют 0, 1 или N экземпляров сущности А (Рис. 23). Рисунок 23 – Связь многие-к-одному многие-ко-многим (M:N). В этом случае одному экземпляру сущности A соответствуют 0, 1 или N экземпляров сущности B, и наоборот, одному экземпляру сущности B соответствуют 0, 1 или N экземпляров сущности А (Рис. 24). Рисунок 24 – Связь многие-ко-многим Другой важной характеристикой связи помимо ее степени является класс принадлежности входящих в нее сущностей. Существует обязательный и необязательный классы принадлежности. Рассмотрим примеры степени связи один-к-одному: 1. Если рассматривать традиционный брак, то степень связи между сущностями Мужчина и Женщина будет 1:1. Кроме того, каждый мужчина, состоящий в браке, обязательно ДОЛЖЕН иметь жену. Таким образом, говорят, что сущность Женщина имеет обязательный класс принадлежности. И, наоборот, каждая женщина, состоящая в браке, ДОЛЖНА иметь мужа. То есть, сущность Мужчина также имеет обязательный класс принадлежности (Рис. 25). Рисунок 25 – Связь 1:1, обязательные классы принадлежности 2. Сотрудник руководит отделом (Рис. 26). Поскольку сотрудник может руководить только ОДНИМ отделом, а в отделе может быть только ОДИН руководитель, то степень связи в этом примере 1:1. Кроме того, в каждом отделе ДОЛЖЕН быть руководитель, т.е. каждому экземпляру сущности Отдел ДОЛЖЕН соответствовать экземпляр сущности Сотрудник (сущность Сотрудник имеет обязательный класс принадлежности). С другой стороны, далеко не все сотрудники должны быть руководителями, т.е. сотрудник МОЖЕТ (но не должен) быть руководителем. Таким образом, есть экземпляры сущности Сотрудник, которым не соответствует ни один экземпляр сущности Отдел (необязательный класс принадлежности). Рисунок 26 - Связь 1:1, обязательный и необязательный классы принадлежности 3. Человек читает книгу (Рис. 27). Человек может читать сразу только ОДНУ книгу, а конкретная книга может быть читаема только ОДНИМ человеком, следовательно, степень связи 1:1. Человек МОЖЕТ читать книгу, а может ничего не читать. С другой стороны не каждая книга должна читаться, некоторые стоят на полке. Таким образом, обе сущности имеют необязательный класс принадлежности. Рисунок 27 - Связь 1:1, необязательные классы принадлежности Рассмотрим примеры степени связи один-ко-многим (многие-к-одному): 4. В процессе обучения студенты объединены в группы. Каждая группа может содержать множество студентов, а каждый студент может входить только в одну группу, т.е. степень связи 1:N (Рис. 28). Каждая группа ДОЛЖНА содержать студентов, а каждый студент ДОЛЖЕН быть зачислен в конкретную группу, т.е. обе сущности имеют обязательные классы принадлежности Рисунок 28 - Связь 1:N, обязательные классы принадлежности 5. Поставщики продуктов имеют один юридический адрес, следовательно, ДОЛЖНЫ находиться в одном конкретном городе. А в одном городе МОГУТ находиться один, несколько или ни одного поставщика. Т.е. связь будет N:1, сущность Города будет иметь обязательный, а сущность Поставщики - необязательный классы принадлежности (Рис. 29). Рисунок 29 - Связь 1:N, обязательный и необязательный классы принадлежности Если существование сущности x зависит от существования сущности у, то x называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность" у - сильной). Степень связи для сильной сущности всегда будет 1 и обязательный класс принадлежности. Класс принадлежности и степень связи для зависимой сущности могут быть любыми. 6. В магазине происходит продажа продуктов. Продукт не может быть продан, если его нет в магазине. Поэтому сущность Продажи является зависимой от сущности Продукты (Рис. 30). Продукт МОЖЕТ быть продан в разные дни (а может быть вообще не продан), конкретная продажа связана только с одним продуктом. Таким образом, степень связи N:1, сущность Продажи имеет необязательный, а сущность Продукты - обязательный классы принадлежности (в самом деле, продажа без продукта теряет смысл) Рисунок 30 – Зависимая и независимая сущности Рассмотрим пример степени связи многие-ко-многим: 7. Продукты в магазин поставляются поставщиками. Каждый продукт, имеющийся в магазине, ДОЛЖЕН быть поставлен одним или несколькими поставщиками, а каждый из поставщиков МОЖЕТ поставлять один или несколько продуктов или не поставлять ни одного. Т.е. степень связи M:N (Рис. 31), а класс принадлежности для Поставщиков - обязательный, для Продуктов - необязательный. Рисунок 31 - Связь M:N, обязательный и необязательный классы принадлежности 8. Между одними и теми же сущностями могут существовать несколько связей, например: С одной стороны продукты в магазин поставляются заказчиками, с другой стороны, чтобы продукты были поставлены в магазин, необходимо заказать поставщикам необходимые продукты. Таким образом, между сущностями Продукты и Поставщики существуют связи «Поставляют» и «Заказаны» (Рис. 32). Связь «Поставляют» рассмотрена в предыдущем примере. Рассмотрим подробнее связь «Заказаны». Каждый продукт ДОЛЖЕН быть заказан одному или нескольким поставщикам, каждый поставщик МОЖЕТ получить заказ на один или несколько продуктов или вообще не получить заказ. Рисунок 32 – Несколько связей между двумя сущностями 9. Рассмотрим сущности Врач и Пациент. Пациент ДОЖЕН иметь одного лечащего врача, а врач МОЖЕТ лечить несколько пациентов. Кроме того, пациент МОЖЕТ иметь нескольких врачей-консультантов, а врач МОЖЕТ консультировать нескольких пациентов (Рис.33). Рисунок 33 – Несколько связей между двумя сущностями 4.5.3 Пример построения модели «сущность-связь» В процессе построения диаграммы "сущность-связь" можно выделить несколько этапов: • Определение списка сущностей выбранной предметной области • Определение списка атрибутов сущностей • Описание связей между сущностями (степени, классы принадлежности связей, а также атрибуты связей, если они необходимы) • Организация данных в виде диаграммы "сущность-связь" В качестве примера построим диаграмму, отображающую связь данных для информационной системы учета продажи продуктов в магазине. БД должна хранить информацию о продуктах, поставляемых в магазин, их ежедневной продаже, заказах на поставку продуктов, а также о поставщиках продуктов. Составим список сущностей, необходимых для реализации поставленной задачи: 1. Продукты Для этой сущности необходимы следующие атрибуты: • Код продукта - уникальный идентификатор, ключевой атрибут • Продукт - название продукта • Единица измерения - литры, килограммы, штуки и т.п. • Срок хранения в днях - для определения даты окончания срока годности продукта • Условия хранения - температура, влажность и т.п. 2. Поставщики • Код поставщика - уникальный идентификатор, ключевой атрибут • Поставщик - название организации или ФИО физического лица • Код города - выделим отдельно город, где находится поставщик, для удобства дальнейшей • работы (например, для поиска) • Адрес - поскольку город выделен в отдельный атрибут, то в адресе остается улица и дом (а • также квартира - для физического лица) • ФИО директора • Телефон • Факс 3. Продажи • Дата продажи • Код продукта - какой именно продукт был продан • Количество - сколько продано этого продукта в тех единицах измерения, которые указаны • для этого продукта в сущности Продукт • Цена продажи - цена при продаже за единицу продукта 4. Города - поскольку мы выделили отдельно город из адреса поставщика, то возникает необходимость в этой сущности • Код города - уникальный идентификатор, ключевой атрибут • Город Сократив для удобства названия атрибутов, получим список сущностей: • Продукты(КодПрод, Продукт, ЕдИзм, СрокХран(дней), УсловияХран) • Поставщики(КодПост, Поставщик, КодГорода, Адрес, ФИОдиректора, Телефон, Факс) • Продажи(ДатаПродажи, КодПрод, Количество, ЦенаПродажи), обратите внимание, что в этой сущности ключ составной, поскольку каждый день продается множество продуктов, и конкретный продукт может быть продан в разные дни • Города(КодГорода, Город) Рассмотрим связи, существующие между описанными выше сущностями: 1. Продукты в магазин поставляются поставщиками, т.е. существует связь M:N «Поставляют» между сущностями Продукты и Поставщики (рис. 34). Эта связь имеет следующие атрибуты: • Дата поставки • Код поставщика - какой поставщик поставил этот продукт • Код продукта - какой именно продукт был поставлен • КоличествоП - сколько поставлено этого продукта в тех единицах измерения, которые • указаны для этого продукта в сущности Продукт • Цена поставки - цена при поставке за единицу продукта • Дата изготовления - дата изготовления продукта Ключом будет составной атрибут: Дата поставки, Код поставщика, Код продукта. 2. Продукты должны быть заказаны поставщикам, т.е. существует связь M:N «Заказаны» между сущностями Продукты и Поставщики (Рис. 34). Эта связь имеет следующие атрибуты: • Дата заказа • Код поставщика - какому поставщику заказан этот продукт • Код продукта - какой именно продукт был заказан • КоличествоЗ - сколько поставлено этого продукта в тех единицах измерения, которые указаны для этого продукта в сущности Продукт. Ключом будет составной атрибут: Дата заказа, Код поставщика, Код продукта 3. В магазине происходит продажа продуктов, т.е. существует связь N:1 «Происходит» между сущностями Продажи и Продукты (Рис. 34) 4. Поставщики находятся в определенном городе, т.е. существует связь N:1 «Находятся» между сущностями Поставщики и Города (Рис. 34) После объединения всех фрагментов в общую модель и добавления атрибутов, получится диаграмма "сущность-связь", приведенная на Рис. 34. Рисунок 34. Диаграмма «сущность-связь» учета продажи продуктов в магазине 5. Распределенные информационные системы В некомпьютерных информационных технологиях информационные ресурсы организаций и предприятий, с одной стороны, разделены и распределены логически (по различным подразделениям, службам) и физически (находятся в различных хранилищах, картотеках, помещениях). С другой стороны, информационные ресурсы создаются и используются своей определенной частью или в целом коллективно или индивидуально. Иначе говоря, с одними и теми же документами, картотеками и прочими информационными массивами могут в рамках общего проекта или в своей части одновременно работать несколько сотрудников и подразделений. Первоначальные подходы к созданию баз данных АИС заключались в сосредоточении данных логически и физически в одном месте—на одной вычислительной установке. Однако такая организация информационных ресурсов чаще всего является не совсем естественной сточки зрения традиционных («бумажных») информационных технологий конкретного предприятия (организационной структуры) и при внедрении АИС происходит «ломка» привычных информационных потоков и структур. Все информационные ресурсы предприятия, организации сосредотачиваются централизованно в одном месте, что требует определенных технологических, кадровых и материальных затрат и может порождать ряд новых проблем и задач. Следует отметить, что такому подходу также способствовала и господствующая на начальном этапе автоматизации предприятий и организаций в 70-х годах тогдашняя парадигма вычислительных систем — общая мощная вычислительная установка (main frame) и групповая работа пользователей с удаленных терминалов через системы разделения времени. Опыт внедрения автоматизированных систем управления в различных организационных структурах в 70-е—80-е гг. показал не всегда высокую эффективность подобной автоматизации, когда новые технологические информационно-управленческие подразделения (отдел автоматизации, отдел АСУ, информационная служба и т. п.) и новые электронные информационные потоки зачастую функционировали вместе с сохраняющимися традиционными организационными структурами, а также вместе с традиционными («бумажными», «телефонными») информационными потоками. Осознание подобных проблем постепенно стало приводить к мысли о распределенных информационных системах. 5.1. Понятие распределенных информационных систем, принципы их создания и функционирования Впервые задача об исследовании основ и принципов создания и функционирования распределенных информационных систем была поставлена известным специалистом в области баз данных К. Дейтом в рамках уже не раз упоминавшегося проекта System R, что в конце 70-х — начале 80-х годов вылилось в отдельный проект создания первой распределенной системы (проект System R*). Большую роль в исследовании принципов создания и функционирования распределенных баз данных внесли также и разработчики системы Ingres. Собственно в основе распределенных АИС лежат две основные идеи: • много организационно и физически распределенных пользователей, одновременно работающих с общими данными — общей базой данных (пользователи с разными именами, в том числе располагающимися на различных вычислительных установках, с различными полномочиями и задачами); • логически и физически распределенные данные, составляющие и образующие тем не менее единое взаимосогласованное целое — общую базу данных (отдельные таблицы, записи и даже поля могут располагаться на различных вычислительных установках или входить в различные локальные базы данных). Крис Дейт сформулировал также основные принципы создания и функционирования распределенных баз данных. К их числу относятся: • прозрачность расположения данных для пользователя (иначе говоря, для пользователя распределенная база данных должна представляться и выглядеть точно так же, как и нераспределенная); • изолированность пользователей друг от друга (пользователь должен «не чувствовать», «не видеть» работу других пользователей в тот момент, когда он изменяет, обновляет, удаляет данные); □ синхронизация и согласованность (непротиворечивость) состояния данных в любой момент времени. Из основных вытекает ряд дополнительных принципов: • локальная автономия (ни одна вычислительная установка для своего успешного функционирования не должна зависеть от любой другой установки); • отсутствие центральной установки (следствие предыдущего пункта); • независимость от местоположения (пользователю все равно где физически находятся данные, он работает так, как будто они находятся на его локальной установке); • непрерывность функционирования (отсутствие плановых отключений системы в целом, например для подключения новой установки или обновления версии СУБД); • независимость от фрагментации данных (как от горизонтальной фрагментации, когда различные группы записей одной таблицы размещены на различных установках или в различных локальных базах, так и от вертикальной фрагментации, когда различные поля-столбцы одной таблицы размещены на разных установках); • независимость от реплицирования (дублирования) данных (когда какая-либо таблица базы данных, или ее часть физически может быть представлена несколькими копиями, расположенными на различных установках, причем «прозрачно» для пользователя); • распределенная обработка запросов (оптимизация запросов должна носить распределенный характер—сначала глобальная оптимизация, а далее локальная оптимизация на каждой из задействованных установок); • распределенное управление транзакциями (в распределенной системе отдельная транзакция может требовать выполнения действий на разных установках, транзакция считается завершенной, если она успешно завершена на всех вовлеченных установках); • независимость от аппаратуры (желательно, чтобы система могла функционировать на установках, включающих компьютеры разных типов); • независимость от типа операционной системы (система должна функционировать вне зависимости от возможного различия ОС на различных вычислительных установках); • независимость от коммуникационной сети (возможность функционирования в разных коммуникационных средах); • независимость от СУБД2 (на разных установках могут функционировать СУБД различного типа, на практике ограничиваемые кругом СУБД, поддерживающих SQL). В обиходе СУБД, на основе которых создаются распределенные информационные системы, также характеризуют термином «Распределенные СУБД», и, соответственно, используют термин «Распределенные базы данных». Важнейшую роль в технологии создания и функционирования распределенных баз данных играет техника «представлений» (Views). Представлением называется сохраняемый в базе данных авторизованный глобальный запрос на выборку данных. Авторизованность означает возможность запуска такого запроса только конкретно поименованным в системе пользователем. Глобальность заключается в том, что выборка данных может осуществляться со всей базы данных, в том числе из данных, расположенных на других вычислительных установках. Напомним, что результатом запроса на выборку является набор данных, представляющий временную на сеанс открытого запроса таблицу, с которой (которыми) в дальнейшем можно работать, как с обычными реляционными таблицами данных. В результате таких глобальных авторизованных запросов для конкретного пользователя создается некая виртуальная база данных со своим перечнем таблиц, связей, т. е. со «своей» схемой и со «своими» данными. В принципе, сточки зрения информационных задач, в большинстве случаев пользователю безразлично, где и в каком виде находятся собственно сами данные. Данные должны быть такими и логически организованы таким образом, чтобы можно было решать требуемые информационные задачи и выполнять установленные функции. При входе пользователя в распределенную систему ядро СУБД, идентифицируя пользователя, запускает запросы его ранее определенного и хранимого в базе данных представления и формирует ему «свое» видение базы данных, воспринимаемое пользователем как обычная (локальная) база данных. Так как представление базы данных виртуально, то «настоящие» данные физически находятся там, где они находились до формирования представления. При осуществлении пользователем манипуляций с данными ядро распределенной СУБД по системному каталогу базы данных само определяет, где находятся данные, вырабатывает стратегию действий, т. е. определяет, где, на каких установках целесообразнее производить операции, куда для этого и какие данные необходимо переместить из других установок или локальных баз данных, проверяет выполнение ограничений целостности данных. При этом большая часть таких операций прозрачна (т. е. невидима) для пользователя, и он воспринимает работу в распределенной базе данных, как в обычной локальной базе. Несмотря на простоту и определенную изящность идеи «представлений», практическая реализация подобной технологии построения и функционирования распределенных систем встречает ряд серьезных проблем. Первая из них связана с размещением системного каталога базы данных, ибо при формировании для пользователя «представления» распределенной базы данных ядро СУБД в первую очередь должно «узнать», где и в каком виде в действительности находятся данные. Требование отсутствия центральной установки приводит к выводу о том, что системный каталог должен быть на любой локальной установке. Но тогда возникает проблема обновлений. Если какой-либо пользователь изменил данные или их структуру в системе, то эти изменения должны отразиться во всех копиях системного каталога. Однако размножение обновлений системного каталога может встретить трудности в виде недоступности (занятости) системных каталогов на других установках в момент распространения обновлений. В результате может быть не обеспечена непрерывность согласованного состояния данных, а также возникнуть ряд других проблем. 5.2. Технологии и модели «Клиент-сервер» Системы на основе технологий «Клиент-сервер» исторически выросли из первых централизованных многопользовательских автоматизированных информационных систем, интенсивно развивавшихся в 70-х годах (системы main frame), и получили, вероятно, наиболее широкое распространение в сфере информационного обеспечения крупных предприятий и корпораций. В технологиях «Клиент-сервер» отступают от одного из главных принципов создания и функционирования распределенных систем — отсутствия центральной установки. Поэтому можно выделить две основные идеи, лежащие в основе клиент-серверных технологий: • общие для всех пользователей данные на одном или нескольких серверах; • много пользователей (клиентов) на различных вычислительных установках, совместно (параллельно и одновременно) обрабатывающих общие данные. Иначе говоря, системы, основанные на технологиях «Клиент-сервер», распределены только в отношении пользователей, поэтому часто их не относят к «настоящим» распределенным системам, а считают отдельным, уже упоминавшимся классом многопользовательских систем. Важное значение в технологиях «Клиент-сервер» имеют понятия сервера и клиента. Под сервером в широком смысле понимается любая система, процесс, компьютер, владеющие каким-либо вычислительным ресурсом (памятью, временем, производительностью процессора и т. д.). Клиентом называется также любая система, процесс, компьютер, пользователь, запрашивающие у сервера какой-либо ресурс, пользующиеся каким-либо ресурсом или обслуживаемые сервером иным способом. В своем развитии системы «Клиент-сервер» прошли несколько этапов, в ходе которых сформировались различные модели систем «Клиент-сервер». Их реализация и, следовательно, правильное понимание основаны на разделении структуры СУБД на три компонента: • компонент представления, реализующий функции ввода и отображения данных, называемый иногда еще просто как интерфейс пользователя; • прикладной компонент, включающий набор запросов, событий, правил, процедур и других вычислительных функций, реализующий предназначение автоматизированной информационной системы в конкретной предметной области; • компонент доступа к данным, реализующий функции хранения, извлечения, физического обновления и изменения данных (машина данных). Исходя из особенностей реализации и распределения (расположения) в системе этих трех компонентов различают четыре модели технологий «Клиент-сервер»: • модель файлового сервера (File Server — FS); • модель удаленного доступа к данным (Remote Data Access — RDA); • модель сервера базы данных (DataBase Server — DBS); • модель сервера приложений (Application Server — AS). 5.2.1. Файловый сервер Модель файлового сервера называется моделью удаленного управления данными. Данная модель предполагает следующее распределение функций - на клиенте располагаются почти все части приложения: презентационная часть приложения, прикладные функции, а также функции управления информационными ресурсами. Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД и поддерживает доступ к файлам (рис. 35). Рисунок 35 - Модель файлового сервера Поскольку передача файлов представляет собой длительную процедуру, такой подход характеризуется значительным сетевым трафиком, что может привести к снижению производительности всей системы в целом. Помимо этого недостатка использование файлового сервера несет еще и другие: • на каждой рабочей станции должна находиться полная копия СУБД; • управление параллельностью, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД; • узкий спектр операций манипулирования данными, который определяется только файловыми командами; • защита данных осуществляется только на уровне файловой системы. Основное достоинство этой модели, заключается в том, что в ней уже осуществлено разделение монопольного приложения на два взаимодействующих процесса. При этом сервер может обслуживать множество клиентов, обращающихся к нему с запросами. 5.2.2. Модель удаленного доступа к данным В модели удаленного доступа база данных также хранится на сервере. На сервере же находится и ядро СУБД. На клиенте располагаются части приложения, поддерживающие функции ввода и отображения данных и прикладные функции. Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 36. Рисунок 36 - Модель удаленного доступа Сервер принимает и обрабатывает запросы со стороны клиентов, проверяет полномочия пользователей, гарантирует соблюдение ограничений целостности, выполняет обновление данных, выполняет запросы и возвращает результаты клиенту, поддерживает системный каталог, обеспечивает параллельный доступ к базе данных и ее восстановление. К тому же резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не файловые команды, а запросы на SQL, и их объем существенно меньше. В ответ на запросы клиент получает только данные, соответствующие запросу, а не блоки файлов, как в модели файлового сервера. Тем не менее, данная технология обладает и рядом недостатков: • запросы на языке SQL при интенсивной работе клиентских приложений могут существенно загрузить сеть; • презентационные и прикладные функции приложения должны быть повторены для каждого клиентского приложения; • сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте. 5.2.3. Модель сервера баз данных Технологию "клиент — сервер" поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. В основу данной модели добавлен механизм хранимых процедур и механизм триггеров. Механизм хранимых процедур позволяет создавать подпрограммы, работающие на сервере и управляющие его процессами. Таким образом, размещение на сервере хранимых процедур означает, что прикладные функции приложения разделены между клиентом и сервером. Трафик обмена информацией между клиентом и сервером резко уменьшается. Централизованный контроль целостности базы данных в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД. Триггер — это особый тип хранимой процедуры, реагирующий на возникновение определенного события в БД. Он активизируется при попытке изменения данных — при операциях добавления, обновления и удаления. Триггеры определяются для конкретных таблиц БД. Внедрение триггеров незначительно влияет на производительность сервера и часто используется для усиления приложений, выполняющих многокаскадные операции в БД. В данной модели (рис. 37) сервер является активным, потому что не только клиент, но и сам сервер, используя механизм триггеров, может быть инициатором обработки данных в БД. Поскольку функции клиента облегчены переносом части прикладных функций на сервер, он в этом случае называется "тонким". При всех положительных качествах данной модели у нее все же есть один недостаток — очень большая загрузка сервера. Рисунок 37 - Модель сервера БД 5.2.4. Сервер приложений. Трехуровневая модель Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 38. Рисунок 38 - Архитектура трехуровневой модели Такая архитектура предполагает, что на клиенте располагаются: функции ввода и отображения данных, включая графический пользовательский интерфейс, локальные редакторы, коммуникационные функции, которые обеспечивают доступ клиенту в локальную или глобальную сеть. Серверы баз данных в этой модели занимаются исключительно функциями управления информационными ресурсами БД: обеспечивают функции создания и ведения БД, поддерживают целостность БД, осуществляют функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и так далее. Промежуточному уровню, который может содержать один или несколько серверов приложений, выделяются общие не загружаемые функции для клиентов: наиболее общие прикладные функции клиента, функции, поддерживающие сетевую доменную операционную среду, каталоги с данными, функции, обеспечивающие обмен сообщениями и поддержку запросов. Преимущества трехуровневой модели наиболее заметны в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных. Список использованных источников 1. Гайдамакин Н. А. Автоматизированные информационные системы, базы и банки данных. Вводный курс: учебное пособие. — М.: Гелиос АРВ, 2002. — 368 с, ил. 2. Малыхина, М.П., Базы данных: основы, проектирование, использование: учебник для студ. высш. учеб. заведений. 2-е изд. — СПб.: БХВ, 2007. — 528 с. 3. Архитектура информационных систем: учебник для студ. учреждений высш. проф. образования / Б.Я. Советов, А.И. Водяхо, В.А. Дубенецкий, В.В. Цехановский. – М. : Академия, 2012. – 288 с. 4. Избачков Ю.С., Петров В.Н. Информационные системы: учебн. для вузов. 2-е изд. –СПб.: Питер, 2006. – 656 с. 5. Дейт, К., Жд. Введение в системы баз данных, 7-е изд.: Пер. с англ. – М.: «Вильямс», 2001. – 1072 с. 6. Введение в системы баз данных: учебное пособие / сост. П.В. Бураков, В.Ю. Петров, Санкт-Петербург, 2010. – 128 с. 7. Базы данных: конспект лекций / сост. Н. В. Краморенко. - ДВГУ, Владивосток, 2004. – 85с.