База данных. Реляционная БД.Классификация баз данных

Некоторые термины и определения, используемые при работе с базами данных База данных (БД, database) - поименованная совокупность структурированных данных, относящихся к определенной предметной области. Предметная область - некоторая часть реально существующей системы. На практике для информационных систем наибольшее значение имеет предметная область масштаба отдельного предприятия или корпорации. Система управления базами данных (СУБД) - комплекс программных и языковых средств, необходимых для создания и модификации базы данных, добавления, модификации, удаления, поиска и отбора информации, представления информации на экране и в печатном виде, разграничения прав доступа к информации, выполнения других операций с базой. Реляционная БД - основной тип современных баз данных. Состоит из таблиц, между которыми могут существовать связи по ключевым значениям. Таблица базы данных (table) - регулярная структура, которая состоит из однотипных строк (записей, records), разбитых на столбцы (поля, fields). В концептуальной модели реляционной БД аналогом таблицы является сущность (entity), с определенным набором свойств - атрибутов, способных принимать определенные значения . Ключевой элемент таблицы (ключ, regular key) - такое ее поле (простой ключ) или строковое выражение, образованное из значений нескольких полей (составной ключ), по которому можно определить значения других полей для одной или нескольких записей таблицы. Первичный ключ (primary key) - главный ключевой элемент, однозначно идентифицирующий строку в таблице. В концептуальной модели первичный ключ - минимальный набор атрибутов сущности, однозначно идентифицирующий экземпляр сущности. Связь (relation) - функциональная зависимость между объектами. В реляционных базах данных между таблицами устанавливаются связи по ключам, один из которых в главной (parent, родительской) таблице - первичный, второй - внешний ключ - во внешней (child, дочерней) таблице, как правило, первичным не является и образует связь "один ко многим" (1:N). В случае первичного внешнего ключа связь между таблицами имеет тип "один к одному" (1:1).  Хранимые процедуры (stored procedures) - программные модули, сохраняемые в базе данных для выполнения определенных операций с информацией базы. Объект (object) - элемент информационной системы, обладающий определенными свойствами (properties) и определенным образом реагирующий на внешние события (events). Система - совокупность взаимодействующих между собой и с внешним окружением объектов. Репликация базы данных - создание копий базы данных (реплик), которые могут обмениваться обновляемыми данными или реплицированными формами, отчетами или другими объектами в результате выполнения процесса синхронизации. Транзакция - изменение информации в базе в результате выполнения одной операции или их последовательности, которое должно быть выполнено полностью или не выполнено вообще. Язык SQL (Structured Query Language) - универсальный язык работы с базами данных, включающий возможности ее создания, модификации структуры, отбора данных по запросам, модификации информации в базе и прочие операции манипулирования базой данных. Null - значение поля таблицы, показывающее, что информация в данном поле отсутствует. Классификация баз данных По технологии обработки данных базы данных подразделяются на централизованные и распределенные. Централизованная база данных хранится в памяти одной вычислительной системы. Эта вычислительная система может быть мэйнфреймом - тогда доступ к ней организуется с использованием терминалов - или файловым сервером локальной сети ПК. Распределенная база данных состоит из нескольких, возможно, пересекающихся или даже дублирующих друг друга частей, которые хранятся в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных (СУБД). По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с сетевым доступом. Для всех современных баз данных можно организовать сетевой доступ с многопользовательским режимом работы. Централизованные базы данных с сетевым доступом могут иметь следующую архитектуру: • файл-сервер ; • клиент-сервер базы данных; • "тонкий клиент" - сервер приложений - сервер базы данных (трехуровневая архитектура). Рис. 2.1. Схема работы с БД в локальной сети с выделенным файловым сервером Файл-сервер. Архитектура систем БД с сетевым доступом предполагает выделение одной из машин сети в качестве центральной (файловый сервер). На этот компьютер устанавливается операционная система (ОС) для выделенного сервера (например, Microsoft Windows Server 2003). На нем же хранится совместно используемая централизованная БД в виде одного или группы файлов. Все другие компьютеры сети выполняют функции рабочих станций (могут работать в ОС Microsoft Windows 2000 Professional или Microsoft Windows 98). Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где и производится обработка информации (см. рис. 2.1). При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также локальные БД на рабочих станциях. Рис. 2.2. Схема работы с БД в архитектуре "Клиент-сервер" Клиент-сервер. В этой архитектуре на выделенном сервере, работающем под управлением серверной операционной системы, устанавливается специальное программное обеспечение (ПО) - сервер БД, например, Microsoft  SQL Server  или Oracle. СУБД подразделяется на две части: клиентскую и серверную. Основа работы сервера БД - использование языка запросов (SQL). Запрос на языке SQL, передаваемый клиентом (рабочей станцией) серверу БД, порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту (см. рис. 2.2). Тем самым, количество передаваемой по сети информации уменьшается во много раз. Трехуровневая архитектура функционирует в Интранет- и Интернет-сетях. Клиентская часть ("тонкий клиент"), взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу баз данных. Сервер приложений может быть Web-сервером или специализированной программой (например, Oracle Forms Server) (см. рис. 2.3). Рис. 2.3. Схема работы с БД в трехуровневой архитектуре Дальше >> Ранние подходы к организации баз данных Иерархические базы данных В основе данной модели - иерархическая модель данных. В этой модели имеется один главный объект и остальные - подчиненные - объекты, находящиеся на разных уровнях иерархии. Взаимосвязи объектов образуют иерархическое дерево с одним корневым объектом. Иерархическая БД состоит из упорядоченного набора нескольких экземпляров одного типа дерева. Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя (см. рис. 2.4). Рис. 2.4. Схема иерархической модели данных Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных этой системы. Сетевые базы данных Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков. В сетевой модели данных любой объект может быть одновременно и главным, и подчиненным, и может участвовать в образовании любого числа взаимосвязей с другими объектами. Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно - из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи (см. рис. 2.5). Рис. 2.5. Схема сетевой модели Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL) - организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а позже появилось несколько систем, среди которых IDMS. Современные базы данных Реляционные системы Реляционные системы далеко не сразу получили широкое распространение. В то время как основные теоретические результаты в этой области были получены еще в 70-х годах и тогда же появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД. Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы - в 1970 г. [1]. Принципы проектирования информационных систем Информационная система (ИС) - программно-аппаратный комплекс, предназначенный для хранения и обработки информации какой-либо предметной области. База данных - важнейший компонент любой информационной системы. Хорошо структурированная информация в базе данных позволяет не только беспроблемно эксплуатировать систему и выполнять ее текущее обслуживание, но и модифицировать и развивать ее при модернизации предприятия и изменении информационных потоков, законодательства и форм отчетности. демо В нашей стране в списке действующих ГОСТов по разработке автоматизированных систем (по данным Стандартинформ http://www.vniiki.ru/catalog_v.asp?page=1) следующие: • ГОСТ 34.003-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения"; • ГОСТ 34.201-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем"; • ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания"; • ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы". На разработку программной документации действуют стандарты класса ЕСПД (ГОСТ 19.101-77 "Единая система программной документации. Общие положения" и т.д.) Стадии и этапы создания автоматизированных систем (АС) в соответствии с ГОСТ 34.601-90 приведены в табл. 1.1 Стадии и этапы создания АС по ГОСТ 34.601-90 Стадии Этапы работ 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. Послегарантийное обслуживание Для проектирования концептуальной модели и формирования физической модели базы данных информационной системы можно использовать инструментальные CASE-средства (Computer-Aided Software System Engineering), например, Case Studio, SyBase Power Designer, ERWin Data Modeler и др. Данные системы применяются при описании модели данных стандарт IDEF1X и позволяют генерировать программный код на языках SQL, VBScript, JScript, либо работать с другими технологиями для переноса физической модели в реальные СУБД, которыми могут быть Oracle, Microsoft SQL Server, IBM DB2, Informix, Microsoft Access и др. На рис. 1 приведена схема, показывающая взаимосвязь основных терминов в области проектирования баз данных и работы с ними. Рис. 1. Взаимосвязь основных терминов в области проектирования баз данных и работы с ними Выбор системы для разработки приложений, работающих с базой данных, сложное и ответственное решение. Такую возможность имеют универсальные системы программирования: Visual C++ и C#, Delphi, Visual Basic и др. Однако специализированные языки программирования в составе СУБД располагают огромным количеством процедур и функций для работы с базами данных, специальными библиотеками, механизмами для ускорения работы с большими базами данных. В связи с повсеместным распространением Интранета, Экстранета и Интернета, многие системы имеют возможность создания трехуровневой сервис-ориентированной архитектуры Web-приложений для работы с базами данных. В качестве аппаратных средств наиболее часто используются компьютеры на базе процессоров Intel с операционной системой Microsoft Windows (NT, 2000, XP), локальная сеть обычно строится с использованием возможностей этой ОС, файловый сервер и сервер баз данных может использовать ОС Microsoft Windows NT, 2000, Server 2003 либо другую операционную систему для выделенных серверов (например, Unix или NetWare). В настоящее время в эксплуатации на крупных предприятиях находятся комплексные ИС управления предприятиями (КИС, корпоративные системы, ERP -системы), такие как R/3 фирмы SAP, Oracle E-Business Suite, BaanERP. Среди российских разработок приближаются по функциональности к системам класса ERP " Галактика ", " Флагман ", " Парус ". По данным аналитической компании IDC за 2004 г., объем российского рынка интегрированных систем управления предприятием (ИСУП) вырос на 52,8% и достиг 195 млн. долл. Уже третий год подряд темпы его роста превышают аналогичный показатель ИТ отрасли в целом (1.1). Таблица 1.1. Объем российского рынка интегрированных систем управления предприятием в 2014 г. Название компании Доля (%) SAP 40,6 Oracle 22,8 Microsoft 10,9 Galaktika 8,2 1C 4,6 Epicor-Scala 3,7 BAAN 2,4 Остальное 6,8 ВСЕГО 195,15 млн. долл. Многие ERP -системы могут устанавливаться и функционировать на различных операционных системах и серверах баз данных (многоплатформенные системы). База данных подобных систем состоит из нескольких тысяч таблиц (Baan ERP 5.0с - более 2500 таблиц информации по одному предприятию). Любая сложная система для обеспечения ее надежного функционирования строится как иерархическая система, состоящая из отдельных подсистем и модулей, которые взаимодействуют между собой и используют общую базу данных. На рис. 2 приведена схема подсистем и модулей КИС «Флагман» Рис. 2. Схема подсистем и модулей КИС "Флагман" При проектировании сложных информационных систем используется метод декомпозиции - система разбивается на составные части, которые связаны, взаимодействуют друг с другом и образуют иерархическую структуру. Иерархический характер сложных систем хорошо согласуется с принципом групповой разработки. В этом случае деятельность каждого участника проекта ограничивается соответствующим иерархическим уровнем. Классический подход к разработке сложных систем представляет собой структурное проектирование, при котором осуществляется алгоритмическая декомпозиция системы по методу " сверху вниз ". Именно в этом случае можно построить хорошо функционирующую систему с общей базой данных, согласованными форматами использования и обработки информации на всех участках, с оптимальным взаимодействием всех подсистем. Исторически сложилось так, что некоторые системы разрабатывались по методу " снизу вверх ": вначале создавались отдельные автоматизированные рабочие места (АРМы), затем предпринимались попытки объединения их в единую информационную систему. Подобные разработки для крупных систем не могут быть успешны. Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.    Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных. Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.    Остальные модели являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.    Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.    Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.    Модели данных Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д.. Наиболее популярной из них оказалась модель "сущность-связь".    Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели. Инфологическая модель данных «Сущность-связь»    Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).    Сущность – любой различимый объект, информацию о котором необходимо хранить в базе данных.    Атрибут – поименованная характеристика сущности.    Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.    Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей. Процедура проектирования    Процесс проектирования информационных систем является достаточно сложной задачей. Он начинается с построения инфологической модели данных (п. 2), т.е. идентификации сущностей. Затем необходимо выполнить следующие шаги процедуры проектирования даталогической модели. 1.     Представить каждый стержень (независимую сущность) таблицей базы данных (базовой таблицей) и специфицировать первичный ключ этой базовой таблицы. 2.     Представить каждую ассоциацию (связь вида "многие-ко-многим" или "многие-ко-многим-ко-многим" и т.д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей. 3.     Представить каждую характеристику как базовую таблицу с внешним ключом, идентифицирующим сущность, описываемую этой характеристикой. Специфицировать ограничения на внешний ключ этой таблицы и ее первичный ключ – по всей вероятности, комбинации этого внешнего ключа и свойства, которое гарантирует "уникальность в рамках описываемой сущности". 4.     Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения. 5.     Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством. 6.     Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполнить описанную процедуру нормализации. 7.     Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги. 8.     Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей. При создании проекта информационной системы для проектирования ее базы данных следует определить: 1. объекты информационной системы (сущности в концептуальной модели); 2. их свойства (атрибуты); 3. взаимодействие объектов (связи) и информационные потоки внутри и между ними. При этом очень важен анализ существующей практики реализации информационных процессов и нормативной информации (законов, постановлений правительства, отраслевых стандартов), определяющих необходимый объем и формат хранения и передачи информации. Если радикальной перестройки сложившегося информационного процесса не предвидится, следует учитывать имеющиеся формы хранения и обработки информации в виде журналов, ведомостей, таблиц и т.п. бумажных носителей. Однако предварительно необходимо выполнить анализ возможности перехода на новые системы учета, хранения и обработки информации, возможно, исходя из имеющихся на рынке программных продуктов-аналогов, разработанных крупными информационными компаниями и частично или полностью соответствующими поставленной задаче. Схема формирования информационной модели представлена на рис.4. Рис. 4. Схема формирования информационной модели Концептуальная модель (см. рис.1.4) - отображает информационные объекты, их свойства и связи между ними без указания способов физического хранения информации (модель предметной области, иногда ее также называют информационно-логической или инфологической моделью). Информационными объектами обычно являются сущности - обособленные объекты или события, информацию о которых необходимо сохранять, имеющие определенные наборы свойств - атрибутов. Физическая модель - отражает все свойства (атрибуты) информационных объектов базы и связи между ними с учетом способа их хранения - используемой СУБД. Внутренняя модель - база данных, соответствующая определенной физической модели. Внешняя модель - комплекс программных и аппаратных средств для работы с базой данных, обеспечивающий процессы создания, хранения, редактирования, удаления и поиска информации, а также решающий задачи выполнения необходимых расчетов и создания выходных печатных форм. Создание информационной системы ведется в несколько этапов, на каждом из которых конкретизируются и уточняются элементы разрабатываемой системы. Существуют различные типы схем, иллюстрирующих жизненный цикл разработки ИС. На рис.5 показана каскадная схема с обратной связью. Рис. 5. Каскадная схема жизненного цикла ИС Жизненный цикл разработки сложной системы в этом случае складывается из этапов анализа, проектирования, программирования и тестирования, внедрения и сопровождения, которые выполняются последовательно. По принятым сегодня нормам, над любым проектом ИС работают: • бизнес-аналитики, изучающие и моделирующие бизнес-процессы предметной области; • системные аналитики и архитекторы, проектирующие архитектуру решения, приложений и данных; • авторы кода приложений; • специалисты по тестированию и оценке качества; • авторы документации; • авторы дистрибутивов; • специалисты по внедрению, причем обычно эти функции распределяются между различными специалистами, хотя совмещение ролей все еще практикуется. Для решения задач проектирования сложных систем существуют специальные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF (Icam DEFinition, ICAM - Integrated Computer-Aided Manufacturing - первоначально разработанная в конце 70-х гг. программа ВВС США интегрированной компьютерной поддержки производства). С их помощью можно эффективно проектировать, отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. В настоящий момент к семейству IDEF относятся следующие стандарты: • IDEF0 - Function Modeling - методология функционального моделирования сложных систем. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функциональных блоков. Основана на разработанной компанией SofTech, Inc. в конце 60-х гг. технологии SADT - структурированного анализа и разработки (Structured Analysis and Design Technique). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы; • IDEF1 - Information Modeling - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; • IDEF1X ( IDEF1 Extended) - Data Modeling - методология проектирования реляционных баз данных. Заключается в построении моделей данных типа "сущность-связь" (ERD - Entity-Relationship Diagram) в нотации этого стандарта; • IDEF2 - Simulation Model Design - методология динамического моделирования систем. В настоящее время существуют алгоритмы и их компьютерные реализации, которые позволяют превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (CPN - Color Petri Nets); • IDEF3 - Process Description Capture - методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3 ; • IDEF4 - Object-Oriented Design - методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы; • IDEF5 - Ontology Description Capture - методология онтологического исследования сложных систем. В методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы, и производится ее оптимизация; • IDEF6 - Design Rationale Capture - методология использования рационального опыта проектирования, назначение: сохранение рационального опыта проектирования информационных систем для предотвращения структурных ошибок при новом проектировании; • IDEF7 - Information System Auditing - методология аудита информационной системы; • IDEF8 - User Interface Modeling - методология проектирования интерфейса пользователя; • IDEF9 - Scenario-Driven IS Design - методология анализа имеющихся условий и ограничений, в том числе физических, юридических, политических, и их влияния на принимаемые решения в процессе реинжиниринга; • IDEF10 - Implementation Architecture Modeling - моделирование архитектуры выполнения; • IDEF11 - Information Artifact Modeling - информационное моделирование артефактов; • IDEF12 - Organization Modeling - организационное моделирование; • IDEF13 - Three Schema Mapping Design - трехсхемный дизайн карт; • IDEF14 - Network Design - методология моделирования компьютерных сетей. Позволяет выполнять представление и анализ данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п. Описание стандартов IDEF0 - IDEF5, IDEF9 можно найти на сайтах http://www.idef.ru, http://www.idef.com или http://www.vpg.ru/main.mhtml?PubID=6 В стандарте IDEF0 функциональный блок графически изображается в виде прямоугольника (см. рис. 6) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта, название каждого функционального блока должно быть сформулировано в виде глагола в побудительном наклонении ("выполнять операцию", а не "выполнение операции"). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом: • верхняя сторона имеет значение "Управление" (Control); • левая сторона имеет значение "Вход" (Input); • правая сторона имеет значение "Выход" (Output); • нижняя сторона имеет значение "Механизм" (Mechanism). Рис. 6. Функциональный блок по стандарту IDEF0 Принципы изображения функциональных моделей стандарта IDEF0 используют инструментальные средства моделирования ( CASE -средства - Computer-Aided Software System Engineering), такие как BPwin фирмы Computer Associates и др. В стандарте IDEF1 сущности и связи концептуальной модели изображаются, как показано на рис. 7. Рис. 7. Изображение сущностей и связей концептуальной модели по IDEF1 Метод IDEF1, являясь методом анализа, описывает: • как информация собирается, хранится и обрабатывается на предприятии; • правила и логику управления информацией; • проблемы, возникающие из недостатка хорошего информационного управления. Другие методологии, используемые при моделировании сложных систем: • DFD-технология анализа "потока данных" (Data Flow Diagrams); • Workflow-технология анализа "потока работ". Важное место в моделировании информационных систем занимает методология и системы, использующие UML - унифицированный язык моделирования ( Unified Modeling Language ). UML - язык для спецификации, визуализации, конструирования и документирования сложных информационно-насыщенных объектных систем. В настоящее время зарегистрирован как международный стандарт ISO/IEC 19501:2005 "Information technology - Open Distributed Processing - Unified Modeling Language ( UML )". UML -модель может включать в себя следующие аспекты; 1. Структурный аспект: Use-Case-диаграммы, идентифицирующие бизнес-процессы и бизнес-транзакции, их взаимосвязь, соподчиненность и взаимодействие; Package-диаграммы, описывающие структуру предметной области и иерархическую структуру организации. 2. Динамический аспект: Behavior-диаграммы (Activity, Statechart, Collaboration, Sequence), описывающие поведение (жизненный цикл) бизнес-процесcов в их взаимодействии во времени и в пространстве с привязкой к используемым ресурсам и получаемым результатам. 3. Статический аспект: Class-диаграммы, отражающие совокупность взаимосвязанных объектов, т.е. рассматривающие логическую структуру предметной области, ее внутренние концепции, иерархию объектов и статические связи между ними, структуры данных и объектов ; Deployment-диаграммы, отражающие технологические ресурсы организации. Словарь языка UML включает три вида строительных блоков: • сущности; • отношения; • диаграммы. Сущности в UML - это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей. В UML имеется четыре типа сущностей: • структурные; • поведенческие; • группирующие; • аннотационные. Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существует семь разновидностей структурных сущностей: Класс, Интерфейс, Кооперация, Прецедент, Активный класс, Компонент, Узел. Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей: Взаимодействие и Автомат. Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно - пакет. Аннотационные сущности - пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание. Все разновидности сущностей UML в диаграммах имеют свой способ графического изображения. В языке UML определены четыре типа отношений: • зависимость; • ассоциация; • обобщение; • реализация. Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру ИС. Таким образом, в UMLвыделяют девять типов диаграмм: • диаграммы классов (Class Diagrams); • диаграммы объектов (Objects Diagrams); • диаграммы прецедентов (Use Cases Diagrams); • диаграммы последовательностей (Sequence Diagrams); • диаграммы кооперации (Collaboration Diagrams); • диаграммы состояний (State Diagrams); • диаграммы действий (Activity Diagrams); • диаграммы компонентов (Component Diagrams); • диаграммы развертывания (Deployment Diagram). Инструментальные средства, поддерживающие методологию UML - Rational Rose (Rational Software), Paradigm Plus (CA/Platinum), ARIS (IDS Sheer AG), Together Designer (Borland) и др. Система Rational Rose позволяет строить восемь типов диаграмм UML: диаграммы прецедентов, диаграммы классов, диаграммы последовательностей, диаграммы кооперации, диаграммы состояний, диаграммы действий, компонентные диаграммы, диаграммы развертывания. Основным типом диаграмм, своеобразным ядром моделирования в UML являются диаграммы классов. Кроме UML, предусмотрено использование и других методов (Booch, OMT). Система Paradigm Plus ориентирована на методологию OOCL (Object Oriented Change and Learning) и компонентную технологию проектирования и разработки. Она поддерживает диаграммы различных методов ( UML, CLIPP, TeamFusion, OMT, Booch, OOCL, Martin/Odell, Shlaer/Mellor, Coad/Yourdon). Система ARIS обеспечивает четыре различных "взгляда" на моделирование и анализ: Процессы, Функции (с Целями), Данные, Организация. Для каждого "взгляда" поддерживаются три уровня анализа (требования, спецификации, внедрение). Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и др. Каждый объект моделей ARIS имеет множество атрибутов, которые позволяют контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с workflow-системами и т.д. Ранние подходы к организации баз данных Иерархические базы данных В основе данной модели - иерархическая модель данных. В этой модели имеется один главный объект и остальные - подчиненные - объекты, находящиеся на разных уровнях иерархии. Взаимосвязи объектов образуют иерархическое дерево с одним корневым объектом. Иерархическая БД состоит из упорядоченного набора нескольких экземпляров одного типа дерева. Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя (см. рис. 2.4). Рис. 2.4. Схема иерархической модели данных Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных этой системы. Сетевые базы данных Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков. В сетевой модели данных любой объект может быть одновременно и главным, и подчиненным, и может участвовать в образовании любого числа взаимосвязей с другими объектами. Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно - из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи (см. рис. 2.5). Рис. 2.5. Схема сетевой модели Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL) - организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а позже появилось несколько систем, среди которых IDMS. Современные базы данных Реляционные системы Реляционные системы далеко не сразу получили широкое распространение. В то время как основные теоретические результаты в этой области были получены еще в 70-х годах и тогда же появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД. Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы - в 1970 г. [1]. Техническая статья "Реляционная модель данных для больших разделяемых банков данных" доктора Е.Ф. Кодда, опубликованная в 1970 г., является родоначальницей современной теории реляционных БД. В реляционной модели данные разбиваются на наборы, которые составляют табличную структуру. Эта структура таблиц состоит из индивидуальных элементов данных, называемых полями. Одиночный набор или группа полей известна как запись. . Каждая строка, содержащая данные, называется кортежем, каждый столбец отношения называется атрибутом (на уровне практической работы с современными реляционными БД используются термины "запись" и "поле"). Элементами описания реляционной модели данных на концептуальном уровне являются сущности, атрибуты, домены и связи Сущность - некоторый обособленный объект или событие, информацию о котором необходимо сохранять в базе данных, имеющий определенный набор свойств - атрибутов. Сущности могут быть как физические (реально существующие объекты: например, СТУДЕНТ, атрибуты - № зачетной книжки, фамилия, его факультет, специальность, № группы и т.д.), так и абстрактные (например, ЭКЗАМЕН, атрибуты - дисциплина, дата, преподаватель, аудитория и пр.). Для сущностей различают ее тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр - конкретными значениями свойств. Атрибуты сущности бывают: 1. Идентифицирующие и описательные. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными. 2. Простые и составные. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от особенностей процессов его использования и может быть связано с обеспечением высокой скорости работы с большими базами данных. 3. Однозначные и многозначные - могут иметь соответственно одно или много значений для каждого экземпляра сущности. 4. Основные и производные. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибутавычисляется на основе значений других атрибутов (например, возраст человека вычисляется на основе даты его рождения и текущей даты Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности - множества значений (или домена), которые может принимать данный атрибут. Связи - на концептуальном уровне представляют собой простые ассоциации между сущностями. Например, утверждение "Покупатели приобретают продукты" указывает, что между сущностями "Покупатели" и "Продукты" существует связь, и такие сущности называются участниками этой связи. Существует несколько типов связей между двумя сущностями: это связи " один к одному ", " один ко многим " и " многие ко многим ". Каждая связь в реляционной модели характеризуется именем, обязательностью, типом и степенью. Различают факультативные и обязательные связи. Если сущность одного типа оказывается по необходимости связанной с сущностью другого типа, то между этими типами объектов существует обязательная связь (обозначается двойной линией). Иначе связь является факультативной. Степень связи определяется количеством сущностей, которые охвачены данной связью. Пример бинарной связи - связь между отделом и сотрудниками, которые в нем работают. Диаграмма "сущности-связи" (Entity-Relationship diagrams, или E/R diagram) служит для описания схемы базы на концептуальном уровне проектирования. Метод был предложен в 1976 г. Питером Пин Шань Ченом (Peter Pin Shan Chen) [2]. На диаграммах "сущности-связи" сущности изображаются в виде прямоугольников, атрибуты - в виде эллипсов, а связи - в виде ромбов (см. рис.6). Рис. 6. Диаграмма "сущности-связи" Проектирование схемы БД должно решать задачи минимизации дублирования данных, упрощения и ускорения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Для решения подобных проблем проводится нормализация отношений В рамках реляционной модели данных Э.Ф. Коддом были разработаны принципы нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. Нормализация - это формальный метод анализа отношений на основе их первичного ключа и существующих связей. Ее задача - это замена одной схемы (или совокупности отношений ) БД другой схемой, в которой отношения имеют более простую и регулярную структуру. При работе с реляционной моделью для создания отношений приемлемого качества достаточно выполнения требований первой нормальной формы. Первая нормальная форма (1НФ) связана с понятиями простого и сложного атрибутов. Простой атрибут - это атрибут, значения которого атомарны (т.е. неделимы). Сложный атрибут может иметь значение, представляющее собой объединение нескольких значений одного или разных доменов. В первой нормальной форме устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, "замаскированных" под атрибуты. Отношение приведено к 1НФ, если все его атрибуты - простые, т.е. значение атрибута не должно быть множеством или повторяющейся группой. Для приведения таблиц к 1НФ необходимо разбить сложные атрибуты на простые, а многозначные атрибуты вынести в отдельные отношения. Вторая нормальная форма (2НФ) применяется к отношениям с составными ключами (состоящими из двух и более атрибутов ) и связана с понятиями функциональной зависимости. Если в любой момент времени каждому значению атрибута A соответствует единственное значение атрибута B, то B функционально зависит от A (A  B). Атрибут (группа атрибутов ) A называется детерминантом. Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального ключа. Эта часть уникального ключа определяет отдельную сущность. В реальном проектировании структуры базы данных применяются другой метод - так называемое семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опирающееся на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм "сущность-связь (ERD)" c построением концептуальной модели базы данных. Рис. 2.7. Схема реляционной базы данных Начиная с 1980-х годов, одновременно с широким распространением персональных компьютеров, большое распространение получили так называемые "настольные" реляционные СУБД (Desktop Databases), такие как dBase, FoхBase (его более поздние версии - FoхPro и Visual FoхPro), Paradoх, Access. Наиболее распространенным форматом таблиц подобных реляционных баз стал *.dbf, с которым работали dBase, FoхBase, а также Clipper - система написания программ (в режиме строкового компилятора) для работы с базами данных. В последующем некоторые из них стали полноценными сетевыми СУБД, работающими не только в различных операционных системах в архитектуре " файл-сервер ", но и имеющими возможности для работы с серверами баз данных в архитектуре " клиент-сервер ", а также разработки и использования html-страниц для работы с базами данных. Все СУБД для ПК можно подразделить на 3 вида: 1. Системы управления базами данных в буквальном смысле этого термина, для которых работа с базами возможна только после запуска в работу этой системы без возможности создания автономных программ, работающих с базами. К этим системам относятся: Access, Paradoх, dBase. 2. Системы, имеющие как средства для работы с базами данных, так и возможности разработки исполняемых в операционной системе пользовательских программ (приложений), т. е. средства разработчика программ - FoхPro. 3. Системы для разработки пользовательских программ для работы с базами данных - Clipper, Clarion. Все подобные СУБД имеют в своем составе средства для: • создания баз данных и модификации их структуры; создания индексных файлов; • работы с базами в табличном формате или в виде стандартной формы с расположением полей построчно; при этом возможно редактирование данных, добавление записей, удаление записей, работа с данными из нескольких таблиц базы, вычисление сложных выражений для заданных условий и пр.; • разработки экранных форм, имеющих, кроме редактируемых полей, связанных с базой данных или с переменными памяти, также элементы управления разного вида в виде кнопок; более сложные объекты типа раскрывающихся списков и пр.; • генерации печатных форм - отчетов сложной структуры с группировкой данных, с получением расчетных значений и итогов по группам и общих итогов (сумма, количество, среднее, максимальное, минимальное, и пр.); • разработки программных модулей для сложной обработки данных; • генерации запросов очень сложной структуры - с использованием данных из различных баз, заданием сложных условий отбора данных, сортировки и группировки данных; • в системах, ориентированных на разработчика, дополнительно возможны разработка меню, справочной системы и проекта, включающего все перечисленные выше компоненты и компилирующегося в исполняемую программу. Важными факторами, определяющими выбор СУБД, являются: 1. Формат базы данных, обеспечивающий возможность обмена информацией с другими приложениями операционной системы. Одним из самых распространенных форматов является dbf-формат, с которым работают dBase, FoхBase, FoхPro, Visual FoхPro, Clipper. Его "понимают" все приложения MS Office. Данные из этих баз можно переносить в Word, Eхcel, Access. Свои собственные форматы данных имеют Clarion, Paradoх, Access. 2. Обеспечение секретности и конфиденциальности данных - имеют системы, не ориентированные на разработчика программ: Access, Paradoх. Однако этот фактор может быть реализован при хранении данных на выделенном сервере, где права различных пользователей легко разграничить. Все современные СУБД поддерживают режимы работы в локальной сети многих пользователей с одной базой данных. Некоторые имеют "мастеров", "построителей" и "генераторы выражений" для ускоренной разработки баз данных, экранных форм, отчетов, стандартных приложений. Последние версии СУБД, разработанные для работы в OC Windows, относятся к классу RAD-систем (Rapid Application Development) - средства быстрой разработки приложений - и имеют объектно-ориентированный язык программирования. Это такие системы, как Visual FoхPro, MS Access, Visual dBase и другие. Постреляционные базы данных В настоящее время известны также так называемые "постреляционные" СУБД, в основе которых лежат модель данных в виде многомерных таблиц (например в системе Cache фирмы InterSystems Сorporation) и широкое использование принципов объектно-ориентированного подхода при организации баз данных и программировании. Серверы баз данных В локальных и глобальных компьютерных сетях широко применяются серверы: компьютеры и программные средства для обслуживания клиентов - рабочих станций и/или других серверов. Примерами серверов могут быть: • файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций; • интернет-сервер, обеспечивающий предоставление информации в глобальной сети Интернет; • почтовый сервер, обеспечивающий работу с электронной почтой; • сервер баз данных - СУБД, которая принимает запросы по локальной сети и возвращает информацию, соответствующую запросу. Термин " сервер баз данных " обычно используют для обозначения всей СУБД, основанной на архитектуре " клиент-сервер ", включая и серверную, и клиентскую части. Наиболее распространенными серверами являются в настоящее время Microsoft SQL Server, Oracle, IBM DB2 Universal DataBase, Informix и др. Размер одной базы данных на этих серверах может достигать миллиона терабайт. Распределенные базы данных Основная задача систем управления распределенными базами данных состоит в обеспечении средства интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе. Возможны однородные и неоднородные распределенные базы данных. В однородном случае каждая локальная база данных управляется одной и той же СУБД. В неоднородной системе локальные базы данных могут относиться даже к разным моделям данных. Сетевая интеграция неоднородных баз данных - очень сложная проблема. Многие решения известны на теоретическом уровне, но пока не удается справиться с главной проблемой: недостаточной эффективностью интегрированных систем. Более успешно решается промежуточная задача - интеграция неоднородных SQL-ориентированных систем. Этому в большой степени способствует стандартизация языка SQL. Примером распределенной СУБД может служить System R*. В данной системе разработчики прикладных программ и конечные пользователи остаются в среде языка SQL. Возможность использования SQL основывается на обеспечении System R* прозрачности местоположения данных. Система автоматически обнаруживает текущее местоположение упоминаемых в запросе пользователя объектов данных; одна и та же прикладная программа, включающая предложения SQL, может быть выполнена в разных узлах сети. При этом в каждом узле сети на этапе компиляции запроса выбирается наиболее оптимальный план выполнения запроса в соответствии с расположением данных в распределенной системе. Использование методологии IDEF1X для разработки концептуальной модели данных Важнейшая цель проектирования информационной модели - выработка непротиворечивой структурированной интерпретации реально существующей информации изучаемой предметной области и взаимодействия между ее структурными компонентами. Понятие концептуальной модели данных связано с методологией семантического моделирования данных, т.е. с представлением данных в контексте их взаимосвязей с другими данными. Методология IDEF1X - один из подходов к семантическому моделированию данных, основанный на концепции "сущность-связь" (Entity-Relationship). Это инструмент для анализа информационной структуры систем различной природы. Информационная модель, построенная с помощью IDEF1X -методологии, отображает логическую структуру информации об объектах системы Таким образом, концептуальная модель, представленная в соответствии со стандартом IDEF1X, является логической схемой базы данных для проектируемой системы Основными объектами концептуальной модели являются сущности и связи. Сущность - некоторый обособленный объект или событие моделируемой системы, имеющий определенный набор свойств - атрибутов. Отдельный элемент этого множества называется "экземпляром сущности". Сущность может обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый образец сущности, и может обладать любым количеством связей с другими сущностями. Правила для атрибутов сущности: 1. Каждый атрибут должен иметь уникальное имя. 2. Сущность может обладать любым количеством атрибутов. 3. Сущность может обладать любым количеством наследуемых атрибутов, но наследуемый атрибут должен быть частью первичного ключа сущности-родителя. 4. Для каждого экземпляра сущности должно существовать значение каждого его атрибута (правило необращения в нуль - Not Null). 5. Ни один из экземпляров сущности не может обладать более чем одним значением для ее атрибута. Сущность изображается на ER-диаграмме в виде прямоугольника, в верхней части которого приводится ее название; далее следует список атрибутов. Ключевые атрибуты могут быть выделены подчеркиванием или иным способом. Стандарт IDEF1X описывает способы изображения двух типов сущностей - независимой и зависимой, и связей - идентифицирующих и неидентифицирующих (см. рис. 3.1). увеличить изображение Рис. 3.1. Изображение сущностей и связей по стандарту IDEF1X Каждая сущность может обладать любым количеством связей с другими сущностями. Сущность является независимой, если каждый ее экземпляр может быть однозначно идентифицирован без определения его связей с другими сущностями. Сущность называется зависимой, если однозначная идентификация ее экземпляра зависит от его связей с другими сущностями. Сущность может обладать атрибутами, которые наследуются через связь с родительской сущностью. Последние обычно являются внешними ключами (FK на рис. 3.1) и служат для организации связей между сущностями. Если внешний ключ сущности используется в качестве ее первичного ключа (PK) или как часть составного первичного ключа, то сущность является зависимой от родительской сущности. Если внешний ключ не является первичным и не входит в составной первичный ключ, то сущность является независимой от родительской сущности. Если сущность является зависимой, то связь ее с родительской сущностью называется идентифицирующей, в противном случае - неидентифицирующей. Связь изображается на ER-диаграмме линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. идентифицирующая связь изображается сплошной линией, неидентифицирующая - пунктирной. Связи дается имя, выражаемое грамматической формой глагола. Для связи дополнительно может присутствовать указание мощности: какое количество экземпляров сущности-потомка может существовать для сущности-родителя. Имя связи всегда формируется с точки зрения родителя, так что может быть образовано предложение, если соединить имя сущности родителя, имя связи, выражение мощности и имя сущности-потомка (например "много СТУДЕНТов - сдают - ЭКЗАМЕН"). Принципы изображения концептуальных моделей баз данных стандарта IDEF1 и IDEF1X используют CASE Studio и другие CASE-средства. Подобные системы позволяют на основе концептуальной модели генерировать физическую модель и программный код создания базы данных для большинства наиболее распространенных СУБД и серверов баз данных. В рассматриваемом далее примере концептуальной модели (см. рис. рис. 3.5) все сущности - независимые и связи между ними - неидентифицирующие, хотя возможны и другие варианты ключей и связей. Описание модели данных информационной системы "Контингент студентов университета" Первоначальный этап - создание текстового описания моделируемой системы. Постановка задачи. Главная задача системы - сохранение в базе данных всех необходимых сведений о студентах и их успеваемости, формирование необходимых печатных форм для проведения зачетной и экзаменационной работы преподавателей, генерация сводных итогов по результатам сессии для руководящих работников деканатов, институтов и университета. При разработке системы следует учитывать, что она взаимодействует с системами "Абитуриент", "Стипендия" и "Кадры университета". Информация о студентах первоначально поступает из системы "Абитуриент" и редактируется на уровне деканатов. Она должна также удовлетворять требованиям бухгалтерского учета по начислению стипендий. Система должна использовать справочник специальностей, утвержденный в вышестоящем министерстве. Информация об успеваемости студентов накапливается постоянно и сохраняется за весь период обучения, после чего переносится в архивное хранилище данных. В системе должен использоваться единый справочник дисциплин (предметов) для всех подразделений университета. Концептуальная модель базы данных На концептуальном уровне данные информационной системы состоят из двух основных сущностей: "Студент" и "Успеваемость". Минимальный состав атрибутов и их описание для сущности "Студент" представлены в табл. 3.1. Таблица 3.1. Атрибуты сущности "Студент" Имя атрибута Описание, особенности использования Номер зачетки Первичный ключ - уникальный номер, однозначно идентифицирующий студента университета Фамилия, имя, отчество Является простым с точки зрения экземпляра сущности, при необходимости из общего поля можно выделить составляющие его фамилию, имя и отчество или фамилию и инициалы, однако на практике часто этот атрибут разделяют на 3 отдельных; первый вариант является более экономичным по необходимой общей ширине поля таблицы Дата поступления в университет В нашей стране наиболее часто используется формат работы с датой в виде ДД.ММ.ГГ, что совпадает с немецким (German) форматом дат. Количество цифр года: либо две - для новых систем, поддерживающих заданный в Microsoft Windows годичный интервал (Панель управления - Язык и стандарты - Дата - "При вводе двух цифр года воспринимать их как год между:"), или для систем, в которых аналогичный интервал может быть задан в программе, - либо 4 цифры Факультет (№ факультета) Может быть сложным (кроме кода и названия, может содержать и другие сведения); даже в том случае, если для сущности "Студент" мы хотим сохранять название факультета, оно должно быть представлено в одинаковом виде для каждого факультета, поэтому, в соответствии с принципами нормализации баз данных, этот атрибут следует представить в виде номера, являющегося внешним ключом для новой сущности - "Факультет", в которой каждому номеру, являющемуся первичным ключом, будут соответствовать название и прочие атрибуты этой сущности Специальность(код специальности) Может быть сложным, кроме того, необходимо использовать справочник министерства с утвержденными кодами специальностей, поэтому данный атрибут должен хранить код специальности - внешний ключ для первичного ключа новой сущности "Специальность" Курс Число от 1 до 5 Номер группы Трехзначное число Номер паспорта Состав и вид паспортных данных определяется требованиями бухгалтерской отчетности перед налоговыми органами, фондами социального страхования и пенсионным фондом ... Прочие атрибуты, которых может быть достаточно много В табл. 3.2-3.5 представлены атрибуты сущностей "Успеваемость", "Факультет", "Специальность", "Предмет". Таблица 3.2. Атрибуты сущности "Успеваемость" Имя атрибута Описание, особенности использования Номер зачетки Внешний ключ (к сущности "Студент") Номер семестра Число от 1 до 10 Предмет (№ предмета) Может быть сложным, его следует заменить на его номер (внешний ключ) и связать с новой сущностью "Предмет", состоящий, как минимум, из атрибутов "номер предмета" (первичный ключ) и "название предмета" Оценка Может быть представлена цифрами от 0 до 5 или 1 буквой: например "н" - неявка Дата получения оценки Формат даты обычно ДД.ММ.ГГ Фамилия преподавателя Это поле может быть связано с сущностью "Преподаватель". В данном учебном примере ограничимся простым атрибутом ... Могут быть добавлены и другие атрибуты, например, номер экзаменационной ведомости Таблица 3.3. Атрибуты сущности "Факультет" Имя атрибута Описание, особенности использования Номер факультета Первичный ключ Название факультета Может быть достаточно длинным, но не более 255 символов ... Могут быть добавлены и другие атрибуты, например, декан, номер комнаты деканата и т.д. Таблица 3.4. Атрибуты сущности "Специальность" Имя атрибута Описание, особенности использования Код специальности Первичный ключ - значение из справочника министерства Название специальности Значение из справочника министерства ... Могут быть добавлены и другие атрибуты Таблица 3.5. Атрибуты сущности "Предмет" Имя атрибута Описание, особенности использования № предмета Первичный ключ Название предмета Общий справочник университета ... Могут быть добавлены и другие атрибуты В физической модели каждой сущности будет соответствовать таблица базы данных, а каждому атрибуту - поле таблицы. Имена таблиц и полей лучше задавать с использованием латинских букв и достаточно короткими для удобства использования при программировании и для совместимости с системами, не использующими кириллицу. Состав данных и связи в концептуальной и физической моделях показаны в табл. 3.6 и табл. 3.7. Таблица 3.6. Состав базы данных информационной системы № п/п Сущности концептуальной модели Таблицы физической модели Название Информация 1. "Студент" "SPISOK" "Список студентов" 2. "Успеваемость" "OCENKI" "Оценки студентов" 3. "Факультет" "FCLT" Справочник факультетов 4. "Специальность" "SPECT" Справочник специальностей 5. "Предмет" "PREDMET" Справочник предметов Таблица 3.7. Связи между объектами базы данных информационной системы № п/п Концептуальная модель Физическая модель 1. "Студент" - "Успеваемость" "SPISOK" - "OCENKI" 2. "Студент" - "Факультет" "SPISOK" - "FCLT" 3. "Студент" - "Специальность" "SPISOK" - "SPECT" 4. "Успеваемость" - "Предмет" "OCENKI" - "PREDMET" < Лекция 2 :  Использование системы CASE Studio для проектирования концептуальной и физической моделей базы данных CASE Studio является профессиональным инструментом проектирования баз данных. Система предназначена для визуального создания и модификации диаграмм "сущность-связь" (ERD) и диаграмм потоков данных (DFD). Уровень представления ER-диаграмм может быть различен: от простейшего вида (имена сущностей и связи между ними) и до полной физической модели для выбранной СУБД. Сложные модели данных могут быть разбиты на отдельные логические фрагменты - субмодели. Для разработанных диаграмм далее может быть сгенерирован программный код для создания таблиц, индексов, связей, хранимых процедур, пользователей и других компонентов различных СУБД (см. табл. 3.7.). Кроме того, предусмотрена возможность генерации ER-диаграмм для существующей базы данных ( Reverse Engineering ) с использованием для связи с БД прямого соединения, ODBC или ADO-драйверов. При создании новой модели данных следует задать, для какой СУБД она проектируется, т.к. CASE Studio имеет возможность построения полной физической модели базы данных с использованием индивидуальных свойств каждой БД - типы и свойства атрибутов (стандартные БД и пользователя), возможности описания ключей (первичные и внешние), связей, условий соблюдения ссылочной целостности, пользователей и их групп (ролей); возможности написания хранимых процедур и пр. В последующем можно будет выполнить конверсию физической модели для другой СУБД (меню Model - Database Convertion) с сохранением в виде копии. Создание новой модели может начинаться с задания только имен сущностей и связей между ними, как показано на рис. 3.2, который соответствует описанному выше примеру. Связи (неидентифицирующего типа) следует создавать в направлении от предполагаемого первичного ключа к внешнему. Для всех связей в модели заданы условия соблюдения ссылочной целостности: каскадные изменения при изменении и удалении данных в главной таблице и контроль с запретом неверного ввода (restrict) в операциях обновления и добавления данных в дочерних таблицах (см. рис. 3.3). увеличить изображение Рис. 3.2. Простейший вид ER-диаграммы в системе CASE Studio Далее для каждой сущности в окне свойств (рис. рис. 3.4) можно задать название соответствующей ей таблицы в физической модели, названия атрибутов концептуальной модели и полей физической модели с указанием их типа, размера, с заданием ключей, надписей (Notes), описаний и пр. Следует отметить, что для описания полей физической модели необходимо знать типы данных той СУБД, для которой она разрабатывается. В последующем будут разобраны типы данных полей в системах Visual FoxPro, Microsoft Access и Microsoft SQLServer. Рис. 3.3. Окно описания свойств связи Рис. 3.4. Окно описания свойств сущности и таблицы После описания всех атрибутов и полей может быть использована различная детализация показа концептуальной (в меню View - Display Level, см. рис. 3.5) и физической (в меню View нужно поставить галочку у позиции Physical View) моделей. Рис. 3.5. Меню задания режима показа модели На рис. 3.6 показана концептуальная модель для описанного выше примера, на рис. рис. 3.7 - физическая модель для СУБД Oracle 9i. увеличить изображение Рис. 3.6. Концептуальная модель базы данных увеличить изображение Рис. 3.7. Физическая модель базы данных Далее можно описать права групп пользователей и права отдельных пользователей (меню системы пункт Model - Users Roles и Model - Users), если эту информацию нужно использовать при создании базы данных. На основе описания физической модели был сгенерирован текст программ для создания базы данных в СУБД Oracle (в меню системы пунктModel - Script Generation) и, после конвертации модели, - для Microsoft Access. Общие характеристики СУБД Visual FoxPro (VFP) - современная СУБД для персональных компьютеров, использующая реляционные базы данных, имеющая объектно-ориентированный алгоритмический язык для работы с информацией, методы визуального программирования и достаточно большие возможности (табл. 4.1). Типы данных, которые могут иметь поля таблиц базы данных, приведены в табл. 4.2 и табл. 4.3 Версия системы 8.0 и 9.0 - только в Windows XP, 2000, 2003. Таблица 4.1. Основные максимальные возможности системы Visual FoxPro Наименование предельной величины Предельная величина Количество записей в файле таблицы 1 миллиард Размер файла таблицы 2 гигабайта Количество символов в одной записи 65500 Количество полей в одной записи 255 Количество одновременно открытых таблиц 255 Количество символов в поле таблицы 254 Количество байтов в индексном ключе в некомпаундном индексе 100 Количество байтов в индексном ключе в компаундном индексе 240 Количество открытых индексных файлов для одной таблицы не ограничено Количество открытых индексов во всех рабочих областях не ограничено Количество связей не ограничено Длина выражений связи не ограничена Размер символьных полей 254 Размер числовых полей 20 Количество символов в имени поля в свободной таблице 10 Количество символов в имени поля в таблице, содержащейся в базе данных 128 Диапазон целых чисел + 2 147 483 647 Точность в числовых вычислениях 16 цифр до 9007199254740992 (253) Действительные числа до 10308 или 2 1023 Количество переменных по умолчанию 16384 Количество переменных 65000 Количество массивов 65000 Количество элементов в массиве 65000 Количество строк в исходных программных файлах не ограничено Размер модуля компилируемой программы 64 килобайта Размер процедур в файле не ограничен Количество вложенных DO 128 Количество вложенных READ 5 Количество передаваемых параметров 27 Количество транзакций 5 Количество объектов в отчете не ограничено Длина описания отчета 20 дюймов Количество уровней группировки 74 Длина символьных переменных в отчете 255 Количество открытых окон (всех типов) не ограничено Количество открытых окон BROWSE 255 Количество символов в символьной строке или переменной памяти 16 777 184 Количество символов в командной строке 8192 Количество открытых файлов возможности ОС Количество нажатий клавиш в макро 1024 Количество полей в одном запросе SQL 255 Некоторые достоинства системы: 1. Широко известный формат таблиц баз данных, что позволяет легко организовать обмен информацией с другими приложениями Microsoft Windows. 2. Современная организация реляционных баз данных, позволяющая хранить информацию о таблицах базы, их свойствах, индексах и связях, задавать условия соблюдения ссылочной целостности, создавать локальные и удаленные представления ( Views ), связи с серверами, хранимые процедуры, исполняемые при наступлении более 50 различных видов событий (VFP 7.0-9.0). 3. Высокая скорость работы с большими базами данных. 4. Высокая наглядность работы с базами данных: многофункциональное окно Data session позволяет видеть список открытых таблиц баз данных, их связи, фильтры, порядок по индексам, режимы буферизации, переходить к режимам модификации структуры, к работе с информацией таблиц и пр. 5. Высокая скорость разработки приложений с использованием Мастеров (Wizard), Конструкторов (Designer), Построителей (Builder), режим подсказок IntelliSense при написании текста программ, системы отладки и тестирования программ. 6. Собственный объектно-ориентированный язык работы с базами данных, основу которого составляет широко известное ядро xBase. Наличие в составе системы значительного количества библиотек стандартных классов с доступным для модификации исходным текстом. Возможность использования библиотек других приложений Windows (ActiveX). 7. Возможность разработки приложений, работающих по технологии "клиент-сервер" с данными, размещенными на серверах баз данных Oracle и Microsoft SQL Server и с другими приложениями Microsoft Windows с использованием ODBC и OLE 8. Возможность разработки Интернет-приложений для работы с базами данных и работы с Web-сервисами. Создание и работа с COM и COM+ компонентами (Component Object Model). 9. Возможность разработки проекта для работы с базами данных с компиляцией его в программу, исполняемую в VFP (*.app), в операционной системе Microsoft Windows (*.exe или *.dll) или в Интернет-браузере (*.app). 10. В дистрибутиве системы присутствует большая библиотека примеров, что облегчает освоение всех ее возможностей. Общая характеристика системы Microsoft Access Система Microsoft Access является одним из основных компонентов Microsoft Office и предназначена для работы с реляционными базами данных. Особенность данной СУБД: вся информация базы данных хранится в одном файле (*.mdb). Кроме информации таблиц, в этом же файле сохраняются компоненты приложения для работы с базой данных - экранные формы, отчеты, запросы, программные модули. Для работы с базой данных система использует Microsoft Jet database engine - систему управления базами данных, извлекающую и сохраняющую данные в пользовательских и системных задачах. Ядро базы данных Microsoft Jet можно рассматривать как компонент диспетчера данных, с помощью которого строятся остальные системы доступа к данным, такие как Microsoft Access и Microsoft Visual Basic. Язык написания программных модулей для работы с базой данных - Microsoft Visual Basic for Applications (VBA). Основные возможности системы при работе с базами данных приведены в табл. 7.1. Таблица 7.1. Спецификации системы Microsoft Office Access 2003 Атрибут Максимальное значение База данных Размер файла базы данных (*.mdb) 2 Гбайт за вычетом места, необходимого системным объектам Число объектов в базе данных 32 768 Модули (включая формы и отчеты), свойство Наличие модуля (HasModule) которых имеет значение True) 1 000 Число знаков в имени объекта 64 Число знаков в пароле 14 Число знаков в имени пользователя или имени группы 20 Число одновременно работающих пользователей 255 Таблица Число знаков в имени таблицы 64 Число знаков в имени поля 64 Число полей в таблице 255 Число открытых таблиц 2048 (фактическое число может быть меньше из-за внутренних таблиц, открываемых Microsoft Access) Размер таблицы 2 Гбайт за вычетом места, необходимого системным объектам Число знаков в текстовом поле 255 Число знаков в поле MEMO 65 535 при вводе данных через интерфейс пользователя;1 Гбайт для хранения знаков при программном вводе данных Размер поля объекта OLE 1 Гбайт Число индексов в таблице 32 Число полей в индексе 10 Число знаков в сообщении об ошибке 255 Число знаков в условии на значение записи 2048 Число знаков в описании таблицы или поля 255 Число знаков в записи (кроме полей MEMO и полей объектов OLE) 2000 Число знаков в значении свойства поля 255 Запрос Число установленных связей 32 на одну таблицу за вычетом числа индексов, находящихся в таблице для полей или сочетаний полей, которые не участвуют в связях Число таблиц в запросе 32 Число полей в наборе записей 255 Размер набора записей 1 Гбайт Предел сортировки 255 знаков в одном или нескольких полях Число уровней вложения запросов 50 Число знаков в ячейке на бланке запроса 1024 Число знаков для параметра в запросе с параметрами 255 Число операторов AND в предложении WHERE или HAVING 99 Число знаков в инструкции SQL приблизительно 64000 Форма и отчет Число знаков в надписи 2048 Число знаков в поле 65535 Ширина формы или отчета 22 дюйма (55,87 см) Высота раздела 22 дюйма (55,87 см) Высота всех разделов плюс заголовки разделов (в режиме конструктора) 200 дюймов (508 см) Число уровней вложения форм или отчетов 7 Число полей или выражений, которые можно отсортировать или сгруппировать в отчете 10 Число заголовков и примечаний в отчете 1 заголовок/примечание отчета; 1 заголовок/примечание страницы; 10 заголовков/примечаний групп Число печатных страниц в отчете 65536 Число элементов управления и разделов, которые можно добавить за время существования формы или отчета 754 Число знаков в инструкции SQL, работающей в качестве свойства Источник записей (RecordSource) или Источник строк (RowSource) формы, отчета или элемента управления (оба .mdb и .adp) 32750 Макрос Число макрокоманд в макросе 999 Число знаков в условии 255 Число знаков в комментарии 255 Число знаков в аргументе макрокоманды 255 В табл. 7.2. приведены сведения о типах данных, которые могут иметь поля в таблицах. Таблица 7.2. Типы данных системы Тип данных полей Тип данных в VBA Использование Размер Текстовый String Текст, состоящий из любых символов в кодировке Unicode (2 байта на символ) До 255 символов Поле МЕМО String Текст в кодировке Unicode До 64000 символов Числовой(Байт, Целое, Длинное целое, Одинарное с плавающей точкой, Двойное с плавающей точкой, Код репликации, Действительное) Byte, Integer,Long,Single,Double Числовые данные 1, 2, 4 или 8 байтов. 16 байтов только для кодов репликации (GUID) Дата/времяПолный формат даты. Длинный формат даты. Средний формат даты. Краткий формат даты. Длинный формат времени. Средний формат времени. Краткий формат времени Date Даты и время. 31.12.04 23:55:5931 декабря 2004 г.31-дек-0431.12.0423:55:5911:5523:55 8 байтов(при активации поля всегда показывает полный формат даты) Денежный Currency Значения валют. Денежный тип используется для предотвращения округлений во время вычислений. Предполагает до 15 символов в целой части числа и 4 - в дробной 8 байтов Счетчик Автоматическая вставка последовательных (увеличивающихся на 1) или случайных чисел при добавлении записи. 4 байта. 16 байтов только для кодов репликации (GUID) Логический Boolean Поля, содержащие только одно из двух возможных значений, таких как Да/Нет, Истина/Ложь, Вкл/Выкл. 1 бит Поле объекта OLE String Объекты (например, документы Microsoft Word, электронные таблицы Microsoft Excel, рисунки, звуки и другие двоичные данные), созданные в программах, использующих протокол OLE. Объекты могут быть связанными или внедренными. До 1 гигабайта (ограничено объемом диска) Гиперссылка String Поле, в котором хранятся гиперссылки. Гиперссылка может иметь вид пути UNC, либо URL-адреса До 64000 символов Мастер подстановок Создает поле, позволяющее выбрать значение из другой таблицы или из списка значений, используя поле со списком. При выборе данного типа запускается Мастер для определения этого поля Тот же размер, который имеет первичный ключ, являющийся полем подстановок Система Microsoft Access имеет собственные средства для разграничения прав доступа пользователей к базе данных. Простейшим способом ограничения доступа к базе данных является установка пароля для открытия базы данных (*.mdb). После установки пароля при каждом открытии базы данных будет появляться диалоговое окно, в которое требуется ввести пароль. Этот способ достаточно надежен (Microsoft Access шифрует пароль, поэтому к нему нет доступа при непосредственном чтении файла базы данных), но он действует только при открытии базы данных. После открытия базы все объекты становятся доступными для пользователя (пока не определены другие типы защиты, описанные ниже в этом разделе). Для базы данных, которая совместно используется небольшой группой пользователей или на автономном компьютере, обычно оказывается достаточно установки пароля. База данных может быть зашифрована. При шифровании базы данных ее файл сжимается и становится недоступным для чтения служебными программами или текстовыми редакторами. Дешифрование базы данных отменяет результаты операции шифрования. Нельзя использовать установку пароля на базу данных, если предполагается выполнять репликацию базы. Реплицированные базы данных не могут быть синхронизированы, если установлен пароль базы данных. Защита на уровне пользователей имеет большие возможности по разграничению прав. Этот способ подобен способам, используемым в большинстве сетевых систем. При запуске Microsoft Access от пользователя требуется идентифицировать себя и ввести пароль. Microsoft Access по умолчанию создает две группы: администраторы (группа Admins ) и простые пользователи (группа Users ). Допускается определение других групп и пользователей. Члены группы Admins имеют разрешения на доступ ко всем объектам базы данных. Другим группам и пользователям могут предоставляться разрешения на доступ только к отдельным объектам базы данных. Типовые разрешения на доступ для группы Users могут включать " Чтение данных " и " Обновление данных " для таблиц и запросов, а также " Открытие/запуск " для форм и отчетов. Создание базы данных Процесс создания базы данных рассмотрим на примере описанной ранее (лекция 3) модели базы данных информационной системы "Контингент студентов университета". В системе Microsoft Access процесс создания базы данных выполняется следующим образом. При запуске системы появляется диалоговое окно для выбора режима работы (рис. 7.1), в котором следует выбрать пункт Новая база данных... Рис. 7.1. Создание файла После выбора первого пункта появляется окно для задания пути сохранения и имени новой базы. Выберем папку на диске для сохранения файла базы данных и зададим имя базы - STUDENTS, нажмем на кнопку Создать, после чего откроется окно базы данных. Далее необходимо задать структуру таблиц в соответствии с описанной ранее концептуальной моделью. Можно также воспользоваться сгенерированной ранее системой Case Studio - программой создания таблиц базы данных, однако, далее описан режим создания таблиц с помощью Конструктора. Умение использовать этот режим необходимо каждому пользователю для создания новых таблиц и модификации структуры уже существующих. Выберем пункт Создание таблицы в режиме конструктора (рис. 7.2) и опишем структуру главной таблицы базы данных, т.е. зададим имя, тип, размер каждого поля таблицы, а также первичный ключ (если необходимо), индексированные поля и подпись (рис. 7.3). Имена полей лучше писать латинскими буквами, в одно короткое слово - для удобства использования их в запросах и программах, работающих с базой данных; задание подписей для полей облегчает разработку экранных форм и отчетов. Рис. 7.2. Окно базы данных Рис. 7.3. Описание структуры таблицы в конструкторе Структура таблицы SPISOK приведена в табл. 7.3. Таблица 7.3. Структура таблицы SPISOK Имя поля Тип данных Размер поля Индексированное поле Подпись NZ Текстовый 8 Да (Совпадения не допускаются) № зачетки FIO Текстовый 45 Фамилия, имя, отчество DATA_P Дата/время Краткий формат даты Дата поступления N_FCLT Числовой Байт Да (Совпадения допускаются) Факультет N_SPECT Текстовый 7 Да (Совпадения допускаются) Специальность KURS Числовой Байт Курс N_GRUP Текстовый 10 Группа N_PASP Текстовый 10 Номер паспорта Для поля NZ следует задать свойство "Ключевое поле", т.к. номер зачетки - уникальный для каждого студента и однозначно его идентифицирует в таблице базы. По окончании описания структуры таблицы даем команду Сохранить (на стандартной панели инструментов, в меню - раздел Файл, или при закрытии окна конструктора) и задаем название таблицы - SPISOK. Аналогичным образом создаем в базе данных справочник факультетов с именем файла FCLT, структура его приведена в табл. 7.4. Таблица 7.4. Структура таблицы FCLT Имя поля Тип данных Размер поля Индексированное поле Подпись N_FCLT Числовой Байт Да (Совпадения не допускаются) Номер факультета NAME_F Текстовый 120 Название факультета Таблица 7.6. Структура таблицы OCENKI Имя поля Тип данных Размер поля Индексированное поле Подпись NZ Текстовый 7 Да (Совпадения допускаются) Номер зачетки SEMESTR Числовой Байт Семестр N_PREDM Числовой Целое Да (Совпадения допускаются) Предмет BALL Текстовый 1 Оценка DATA_B Дата/время Краткий формат Дата PREPOD Текстовый 45 Преподаватель Таблица 7.7. Структура таблицы PREDMETS Имя поля Тип данных Размер поля Индексированное поле Подпись N_PREDM Числовой Целое Да (Совпадения не допускаются) Номер предмета NAME_P Текстовый 120 Название предмета Далее задаем связи Один ко многим между таблицами в базе, открыв окно Схема данных (выбрав эту команду в контекстном меню для окна базы данных) и перетаскивая название поля первичного ключа к аналогичному полю другой таблицы (см. рис. 7.4.). При этом задаем в окне Изменение связей (см. рис. 7.5.) условия соблюдения ссылочной целостности данных: каскадное обновление связанных полей и каскадное удаление связанных записей. Рис. 7.4. Схема базы данных Рис. 7.5. Задание условий соблюдения ссылочной целостности данных Стандартный режим работы с таблицами Заполнение базы данных информацией следует начинать со справочников - иначе при заполнении главных таблиц возникнут конфликты сохранения ссылочной целостности базы. Например, если в справочнике факультетов не будет номера факультета, указанного для студента, появится сообщение " Введенное значение не подходит для данного поля " и Вы не сможете сохранить данные, пока не укажете правильное значение. Для работы с информацией таблицы базы данных (добавление, редактирование и удаление записей) следует выбрать ее в разделе объектов базы данных "Таблицы" (см. рис. 7.6.) и двойным щелчком мыши открыть. Рис. 7.6. База данных Таблица откроется в стандартном режиме работы с информацией, как показано на рис. 7.7. Рис. 7.7. Стандартный режим работы с таблицей базы данных В таком режиме каждая запись таблицы базы данных представлена как строка, состоящая из столбцов - полей, над которыми показаны подписи полей или, при их отсутствии, имена полей. В нижней части таблицы присутствует пустая запись с символом * в левой колонке - это несуществующая запись, которая добавляется в таблицу, как только в ней появляется какая-либо информация. На нижней рамке окна находятся кнопки для перемещения по таблице, номер текущей записи и информация об общем количестве записей в таблице. Колонка слева с символом + имеется в наличии, если у таблицы есть связь от одной записи данной таблицы ко многим записям связанной с ней таблицы. В данном случае при щелчке мышью на плюсе откроется как подтаблица - список студентов для соответствующего факультета. Настройка подтаблицы присутствует в главном меню в разделе Вставка. В системе Microsoft Access существуют также дополнительные возможности использования в таблицах режима "Подстановка" для показа и выбора данных из раскрывающихся списков ("тип источника строк" - таблица или запрос, список значений или список полей). Этот режим можно создать с помощью Мастера, если выбрать тип поля "Мастер подстановок" или описать самому на странице "Подстановка". В примере этот режим задан для поля N_FCLT таблицы Spisok (см. рис. 7.8.). В дальнейшем для поля с описанными свойствами раздела "Подстановка" на экранной форме будет автоматически создаваться объект типа "Поле со списком". Рис. 7.8. Параметры страницы "Подстановка" в Конструкторе Вид таблицы Spisok с использованием поля со списком для поля N_FCLT показан на рис. 7.9. увеличить изображение Рис. 7.9. Таблица с использованием режима "Подстановка" При работе с таблицей можно задать сортировку записей по одному из полей и фильтр для показа данных, соответствующих заданному условию (см. раздел меню Записи ). После окончания добавления, редактирования или удаления данных следует дать команду Сохранить, или при закрытии окна таблицы выбрать в появившемся окне команду, сохранять или нет изменения. Разработка экранных форм для работы с базой данных Экранные формы позволяют организовать наглядную и удобную работу с базой данных, состоящей из большого количества связанных таблиц реляционной базы данных. В этом случае на одном экране можно организовать работу с главной и подчиненными таблицами, осуществлять выбор данных из таблиц-справочников с использованием раскрывающихся списков, использовать режимы поиска и отбора информации, печати необходимых отчетов на принтере и пр. Имеющийся в системе Мастер разработки экранных форм позволяет легко создавать экранные формы нескольких видов (простые - для работы с данными одной таблицы, более сложные - для работы с несколькими таблицами с использованием подчиненных форм). Полученные формы далее, как правило, приходится дополнять и модифицировать в конструкторе экранных форм для реализации всех необходимых условий работы с базой. Для разработки экранной формы в окне базы данных выбираем объект Формы и на странице форм - режим Создание формы с помощью Мастера. Далее следует ответить на ряд вопросов Мастера: 1. выберите поля для формы - выбираем все поля таблицы SPISOK и все поля таблицы OCENKI (для последней таблицы поле NZрасположим в конце списка, оно будет заполняться автоматически; добавляем его, чтобы убедиться, что на экране мы видим оценки только одного студента); 2. выберите вид представления данных - выбираем подчиненные формы, т.е. расположение данных главной таблицы и связанной с ней на одной форме; 3. выберите внешний вид подчиненной формы - выбираем ленточный ; 4. выберите требуемый стиль - выбираем стандартный стиль ; 5. задайте имена форм - задаем для главной формы название Студенты, для подчиненной формы Оценки студента и на том же экране ниже выбираем пункт Изменить макет формы, после чего нажимаем на кнопку Готово. Полученная экранная форма будет открыта в конструкторе форм, в базе данных на странице Формы появятся две новые - Студенты и Оценки студента. Для более детального отображения в конструкторе подчиненной формы лучше закрыть окно и снова открыть в конструкторе форму Студенты, в этом случае она будет иметь вид, приведенный на рис. 7.10. Рис. 7.10. Экранная форма, созданная с помощью Мастера На полученной форме не все надписи полностью видны, расположение полей тоже можно улучшить. Для формы и всех ее элементов можно открыть окно Свойства, щелкнув правой кнопкой мыши на любом объекте и выбрав в контекстном меню слово Свойства (рис. 7.11.). Кроме того, в контекстном меню присутствуют такие важные при оформлении объектов возможности, как "Выровнять" - полезно для выравнивания группы объектов, "Размер", "Цвет:", "Оформление", "Условное форматирование". Рис. 7.11. Окно свойств для объекта Форма, страницы Макет и Данные Все свойства в окне разбиты на группы: Макет - расположение, шрифт, цвет и прочее, связанное с внешним видом объекта; Данные - в этом разделе важнейшее свойство - Данные или Источник записей - для объектов, связанных с редактированием каких-либо данных; События - методы, т.е. процедуры (программы), выполняющиеся для объекта при наступлении определенных событий ( Загрузка, Открытие, До обновления, После обновления и пр.); Другие - прочие свойства. На экранной форме присутствуют элементы (объекты) следующих типов: Надпись - текст на форме, обычно не изменяющийся. Главные свойства этого объекта присутствуют на странице Макет окна свойств (рис. 7.12.). Поле - поле редактирования, связанное с полем базы данных или переменной. Главное свойство этого объекта - строка Данные на странице Данные окна свойств (рис. 7.13.). Рис. 7.12. Окно свойств объекта типа Надпись Рис. 7.13. Окно свойств объекта типа Поле Подчиненная форма - вложенная форма для таблицы данных, связанной с главной таблицей, на которой могут присутствовать такие же элементы, как и на основной форме. Поле со списком - сложный элемент, предоставляющий возможность показывать данные справочных таблиц, списков или массивов и заносить выбранные значения в поле другой таблицы (9-й элемент панели, окно свойств, см. рис. 7.14.). Рис. 7.14. Окно свойств объекта типа Поле со списком Рис. 7.15. Панель элементов экранной формы Кроме того, на форме могут присутствовать и другие объекты, которые можно добавлять, используя кнопки Панели элементов (рис. 7.15.), список типов объектов приведен ниже. • Группа переключателей, Выключатель, Переключатель, Кнопка - кнопки и группы кнопок разного вида, связанные с выполнением определенных процедур (5-7 и 11 кнопки на Панели ). При выборе объекта Кнопка запускается Мастер, который предложит вам набор стандартных кнопок перехода по записям таблицы, обработки записей (восстановить, дублировать, печатать и пр.), работы с формой, с отчетами (печатать, просмотреть, отправить в файл или по почте), работы с приложениями и разное. Кнопки можно создать с помощью Мастера, при этом программный код, связанный с их действием, уже будет присутствовать (рис. 7.16.). Рис. 7.16. Окно Мастера создания кнопок • Флажок - поле, связанное обычно с полем таблицы логического типа, в котором стоит галочка или нет (6-й элемент Панели ). • Список - список данных для выбора одного из значений (10). • Рисунок - вставка рисунка в форму (12). • Свободная рамка объекта - любой объект Windows-приложений, редактирование которого будет возможно вызовом соответствующего приложения (13). • Присоединенная рамка объекта - для работы с полями таблиц типа "поле объекта OLE " (14). • Набор вкладок - многостраничная форма (16). • Линия, Прямоугольник - элементы оформления (18, 19). Для использования экранной формы нужно запустить ее в работу. Для этого закроем окно конструктора и выберем команду Открытьформы Студенты. Вид формы при работе с базой данных приведен на рис. 7.17. Рис. 7.17. Работа с базой данных с использованием экранной формы В данном режиме можно редактировать существующие записи, добавлять новые в список студентов и список оценок для каждого студента. Для удаления записей можно добавить с помощью Мастера кнопку категории Обработка записей с действием Удалить запись на основную форму. При работе с формой можно задать сортировку записей по одному из полей и фильтр для показа только тех данных, которые соответствуют заданному условию (см. раздел Записи меню системы Access ). Как было сказано выше, для данной формы можно сделать значительные усовершенствования, повышающие удобства работы с базой данных. Прежде всего, в Конструкторе изменим расположение полей и расширим надписи. Далее добавляем на форму объекты Поле со списком для выбора из справочных таблиц специальности (с занесением соответствующего номера в главную таблицу) и предмета (с занесением его номера из справочника в таблицу оценок). Эти основные свойства описываются с помощью Мастера, который запускается автоматически при добавлении этого типа объекта к форме. На первом шаге Мастера выбираем пункт Объект Поле со списком будет использовать значения из таблицы или запроса, на втором - выбираем из списка нужную нам справочную таблицу, на третьем - выбираем все поля (номер и название), на четвертом шаге - оставляем галочку у флажка скрыть ключевой столбец и задаем ширину поля для названия, на пятом - задаем условие сохранить в поле и выбираем из списка поле главной таблицы, в котором будет сохраняться значение ключевого поля справочной таблицы. Далее нажимаем Готово. Надпись для Поля со списком можно удалить. После всего этого форма будет иметь в Конструкторе вид, приведенный на рис. 7.18. увеличить изображение Рис. 7.18. Усовершенствованная экранная форма в Конструкторе форм В режиме работы с базой данных в усовершенствованной форме можно видеть названия факультетов, специальностей, предметов и выбирать их из справочных таблиц с помощью раскрывающихся списков (рис. 7.19.). увеличить изображение Рис. 7.19. Работа с базой данных с использованием экранной формы, в которой присутствуют объекты Поле со списком Разработка отчетов Для разработки печатных форм - отчетов, отражающих информацию базы данных - в системе Access можно использовать режим Создание отчета с помощью Мастера раздела базы Отчеты, с усовершенствованием отчета в дальнейшем в режиме Конструктора отчетов. Отчеты могут быть созданы на основе всей информации, присутствующей в таблицах базы, но чаще для отчетов необходимо отобрать нужную информацию из базы с использованием SQL-запроса и на основе его создать отчет. Важным свойством отчетов является возможность группировки данных и получения итоговых данных для групп и всего отчета. Поставим задачу разработать отчет, в котором показаны оценки всех студентов с группировкой данных по факультетам, курсам, группам. Для этого выбираем раздел Отчеты и режим Создание отчета с помощью Мастера. На первом шаге Мастера выбираем поля главной таблицы базы ( SPISOK ), которые мы хотим показать в отчете, и все поля дочерней таблицы оценок ( OCENKI ) (рис. 7.20.). Рис. 7.20. Выбор полей для отчета в Мастере отчетов На втором шаге Выберите вид представления данных - выбираем первый вариант, когда выделена таблица SPISOK. На третьем шаге задаем группировку данных по факультетам, курсам и группам. Более трех уровней группировки Мастер задать не позволяет (рис. 7.21.). Рис. 7.21. Группировка данных в отчете Сортировку на следующем шаге не задаем. На пятом шаге выбираем вид макета для отчета по левому краю, на следующем - стиль отчета - обычный, далее задаем название отчета Студенты и их оценки и нажимаем кнопку Готово. Полученный отчет в режиме Конструктора представлен на рис. 7.22. увеличить изображение Рис. 7.22. Отчет, созданный с помощью Мастера В полученном отчете присутствуют объекты трех видов - Поле, которое в отчете будет показывать данные поля таблицы базы или запроса, Надпись - любой текст в отчете, и Линия - элемент оформления. В Конструкторе отчет разбит на отдельные зоны, информация которых может присутствовать в отчете один раз ( Заголовок отчета и Примечание отчета ), в начале и в конце каждой страницы ( Верхний колонтитул и Нижний колонтитул ), в начале и в конце каждой группы ( Заголовок группы и Примечание группы, групп может быть много) и для каждой записи таблицы ( Область данных ). Зоны Примечания: более правильно было бы назвать Итоги:, т.к. здесь можно поместить поля общих итогов (сумма, среднее и пр.) для группы или всего отчета. Полученный отчет можно просмотреть на экране, отправить на принтер (например, с использованием соответствующих кнопок на стандартной панели инструментов), в Microsoft Word или Excel (из режима предварительного просмотра). Вид отчета в режиме предварительного просмотра приведен на рис. 7.23. Рис. 7.23. Отчет в режиме предварительного просмотра Созданный Мастером отчет весьма несовершенен и излишне приукрашен жирными линиями, крупным шрифтом. В отчет необходимо добавить названия факультетов, специальностей и предметов и изменить их подписи. Для добавления новых объектов следует использовать "Панель элементов" или окно "Список полей" (главное меню "Вид" - "Список полей"), для модификации - окно свойств объекта и контекстное меню, для настройки параметров страницы (полей и размера бумаги) следует воспользоваться соответствующим пунктом в разделе Файл главного меню системы. Рис. 7.25. Построитель запросов для свойства "Источник записей" отчета После добавления новых таблиц в окне "Список полей" станут доступны для использования новые поля данных. Нам необходимо добавить поля названий из справочных таблиц. Для этого можно использовать 3 способа: 1. Перетащить мышкой названия поля из окна "Список полей" в нужное место отчета в Конструкторе. 2. Выбрать кнопку "Поле" в Панели элементов, щелкнуть мышкой на том месте отчета, где должно располагаться новое поле, задать его главное свойство (в окне Свойства) - "Данные" (выбором из раскрывающегося списка) - соответствующее поле таблицы базы данных и другие свойства, связанные с внешним видом; подпись для данных следует удалить. 3. Скопировать существующее поле отчета (например, N_FCLT) и задать для него новое свойство " Данные ". Третий способ имеет преимущество - при копировании сохраняются свойства раздела " Макет ", заданные для полей данного отчета (шрифт, его размер, насыщенность и пр.). Кроме того, в окне " Сортировка и группировка " (его можно открыть из контекстного меню или пункта "Вид" главного меню) зададим наличие Примечаний для всех групп (см. рис. 7.26.). Рис. 7.26. Окно "Сортировка и группировка" отчета В зоны примечаний поместим вычисляемые поля, которые будут показывать средние оценки для студента, группы, факультета и для всего отчета. При создании вычисляемых полей проще всего скопировать поле BALL из зоны "Область данных" в зону "Примечание группы:", далее перейти в окно свойств этого объекта и в пункте Данные нажать на кнопку с многоточием, после чего откроется окно Построителя выражений, где можно найти в списке функций AVG (среднее) и задать выражение AVG (BALL) (рис. 7.27.). Рис. 7.27. Создание вычисляемого поля для зоны примечаний отчета Далее следует поместить в отчет Надпись "средняя оценка студента", после чего скопировать это поле и надпись в другие зоны отчета. Вид отчета после модификации приведен на рис. 7.28. увеличить изображение Рис. 7.28. Отчет после его модификации в Конструкторе Отчет при печатании на бумаге будет выглядеть, как показано на рис. 7.29. увеличить изображение Рис. 7.29. Окончательный вариант отчета, напечатанный на принтере Использование запросов Для работы с запросами и для их сохранения в базе в системе Access присутствует специальный раздел, который позволяет создавать новые запросы в режиме конструктора или с помощью Мастера. Запросы в системе Access бывают нескольких видов: 1. Запрос для отбора данных по заданным сложным условиям из одной или нескольких таблиц баз данных, с группировкой данных для расчета итогов, с показом результатов выполнения запроса в виде таблицы, либо с использованием его для форм и отчетов; после редактирования данных в таблице запроса данные таблиц базы могут обновляться (с некоторыми ограничениями). 2. Перекрестный запрос с формированием двухмерной итоговой таблицы, с группировкой по двум выражениям, одно из которых становится заголовком строки, другое - заголовком столбца. 3. Запрос на создание новой таблицы. 4. Запросы на изменение данных: ◦ обновление данных - команда занесения общих изменений в группу записей одной или нескольких таблиц; ◦ добавление данных - команда добавления группы записей из одной или нескольких таблиц в конец одной или нескольких таблиц; ◦ удаление данных - команда удаления группы записей из одной или нескольких таблиц. Принцип формирования запросов наиболее легко освоить при использовании Мастера запросов. Предположим, нам нужно отобрать тех студентов, которые по предмету Математика имеют только отличные оценки по результатам первого семестра. Для создания запроса выбираем в разделе Запросы базы режим Создание запроса с помощью Мастера. На первом шаге следует выбрать таблицы и поля, которые нужно включить в запрос. Выбор полей может быть выполнен из нескольких таблиц базы. Для нашего примера выбираем из таблицы SPISOK все поля, кроме DATA_P и N_PASP, из таблицы OCENKI - первые 4 поля и 2 поля таблицы PREDM (рис. 7.30.). Рис. 7.30. Выбор полей в Мастере запросов На шаге 2 ("подробный или итоговый отчет") выбираем подробный отчет. На последнем шаге 3 задаем название запроса Математика и выберем вариант Изменить макет запроса, после чего нажимаем кнопку Готово. Запрос открывается в конструкторе запросов, его вид показан на рис. 7.31. увеличить изображение Рис. 7.31. Конструктор запросов В верхней части Конструктора запросов показаны таблицы, используемые для отбора данных и связи между ними, в нижней части - таблица для выбора полей, группировки данных (если строки "Групповые операции" нет, нужно выбрать эту команду в главном меню Microsoft Access в пункте "Вид"), задания сортировки и условий отбора. Модифицируем запрос для задания условия отбора данных и упорядочения студентов по их фамилии. Для этого в колонке поля FIOзададим сортировку по возрастанию, для поля SEMESTR зададим условие отбора 1 (первый семестр), для поля BALL зададим условие 5 и для поля PREDMET зададим условие " математика ". Если в условии отбора написать текст в квадратных скобках, при выполнении запроса появится окно для ввода этого параметра. Например, если для поля PREDMET в условии написать Задайте предмет, можно будет использовать один и тот же запрос для отбора данных по разным предметам. Можно также убрать галочки у тех полей, которые вы не хотите показывать на экране. Сохраним запрос и посмотрим его текст в режиме SQL (Structured Query Language). Текст запроса будет выглядеть следующим образом: SELECT Spisok.NZ AS Spisok_NZ, Spisok.FIO, Spisok.N_FCLT, Spisok.N_SPECT, Spisok.KURS, Spisok.N_GRUP, OCENKI.SEMESTR, OCENKI.N_PREDM AS OCENKI_N_PREDM, OCENKI.BALL, PREDMETS.N_PREDM AS PREDMETS_N_PREDM, PREDMETS.NAME_P FROM Spisok INNER JOIN (PREDMETS INNER JOIN OCENKI ON PREDMETS.N_PREDM = OCENKI.N_PREDM) ON Spisok.NZ = OCENKI.NZ WHERE (((OCENKI.SEMESTR)=1) AND ((OCENKI.BALL)="5") AND ((PREDMETS.NAME_P)="математика")) ORDER BY Spisok.FIO; Закроем окно конструктора и выполним запрос командой Открыть или двойным щелчком мышью. Результат отбора данных будет показан на экране в виде таблицы (рис. 7.32.). Следует помнить, что редактирование данных этой таблицы приведет к изменению информации в таблицах базы данных! увеличить изображение Рис. 7.32. Результаты выполнения запроса Результаты выполнения запроса или данные таблиц можно представить в виде диаграмм и графиков. Для представления данных в виде графика в меню Вид выбираем пункт Сводная диаграмма, после чего открывается окно Построителядиаграмм. Методы оформления диаграмм аналогичны использованию объекта Диаграмма Microsoft Graph в программах Microsoft Word или Excel. На рис. 7.33. показана диаграмма для приведенного выше запроса. На рис. 7.34. приведена трехмерная диаграмма для запроса следующего вида: Рис. 7.33. Результаты выполнения запроса с группировкой данных, представленные в виде диаграммы Рис. 7.34. Результаты выполнения запроса с группировкой данных, представленные в виде трехмерной диаграммы С использованием запросов других видов одной командой можно изменять (команда SQL UPDATE ) либо удалять (команда SQL DELETE ) данные множества записей таблицы, отобранных по какому-либо условию, а также добавлять записи из других таблиц (команда SQLINSERT ). Система Microsoft SQL Server Общая характеристика системы Microsoft SQL Server - одна из наиболее мощных систем работы с базами данных в архитектуре "клиент-сервер". Особенность системы - работа сервера только в операционных системах ряда Microsoft Windows NT - NT Server 4.0, 2000 Server, Server 2003, при этом клиентская часть может взаимо-действовать с сервером из Microsoft Windows 98 и других операционных систем. Рекомендуемая файловая система для SQL Server - NTFS, хотя возможна работа и в системе FAT. В своем составе система имеет средства создания баз данных, работы с информацией баз данных, перенесения данных из других систем и в другие системы, резервного копирования и восстановления данных, развитую систему транзакций, систему репликации данных, реляционную подсистему для анализа, оптимизации и выполнения запросов клиентов, систему безопасности для управления правами доступа к объектам базы данных и пр. (см. рис. 8.1). Система не содержит средств разработки клиентских приложений. В таблицах 8.1-8.3 приведены некоторые максимальные возможности системы. Рис. 8.1. Основные компоненты в архитектуре системы Таблица 8.1. Максимальные параметры баз данных Наименование Величина Размер базы данных 1 048 516 TB Количество объектов в базе данных 2 147 483 647 Количество экземпляров сервера на одном компьютере 16 Количество баз данных в одном экземпляре сервера 32767 Количество файлов в базе данных 32767 Количество таблиц в базе данных ограничено количеством объектов в базе Количество полей в таблице базы 1024 Размер файла данных 32 TB Длина идентификаторов 128 символов Уровень вложенных хранимых процедур 32 Уровень вложенных запросов 32 Количество некластерных индексов для одной таблицы базы 249 Количество полей в одном индексе 16 Количество байт в одном индексе 800 Количество таблиц в одном запросе 256 Количество байт в одной строке таблицы 8060 Таблица 8.2. Максимальное количество процессоров, поддерживаемых различными версиями системы в режиме симметричной мультипроцессорной обработки данных (SMP) Операционная система Версия Microsoft SQL Server 2000 Enterprise Edition Standard Edition Personal Edition Developer Edition Desktop Engine SQL Server CE Enterprise Evaluation Edition Microsoft Windows 2000 DataCenter 32 4 2 32 3 - 32 Windows 2000 Advanced Server 8 4 2 8 2 - 8 Windows 2000 Server 4 4 2 4 2 - 4 Windows 2000 Professional - - 2 2 2 - 2 Microsoft Windows NT4.0 Server, Enterprise Edition 8 8 2 8 2 - 8 Windows NT 4.0 Server 4 4 2 4 2 - 4