- •Некоторые термины и определения, используемые при работе с базами данных
- •Принципы проектирования информационных систем
- •Классификация баз данных
- •Ранние подходы к организации баз данных Иерархические базы данных
- •Сетевые базы данных
- •Современные базы данных Реляционные системы
- •12 Правил Кодда
- •Соблюдение условий ссылочной целостности в реляционной базе данных
- •Основные стратегии поддержания ссылочной целостности
- •Дополнительные стратегии поддержания ссылочной целостности
- •Постреляционные базы данных
- •Серверы баз данных
- •Распределенные базы данных
- •Использование методологии idef1x для разработки концептуальной модели данных
- •Описание модели данных информационной системы "Контингент студентов университета"
- •Концептуальная модель базы данных
- •Использование системы case Studio для проектирования концептуальной и физической моделей базы данных
- •Сгенерированная Case Studio sql-программа создания таблиц базы данных для сервера Oracle
- •Сгенерированная Case Studio программа создания таблиц базы данных для субд Access
- •Общая характеристика системы
- •Создание базы данных
- •Стандартный режим работы с таблицами
- •Разработка экранных форм для работы с базой данных
- •Разработка отчетов
- •Использование запросов
- •Компиляция базы данных (mde-файл)
- •Страницы доступа к данным
- •Проект Microsoft Access (adp)
Принципы проектирования информационных систем
Информационная система (ИС) - программно-аппаратный комплекс, предназначенный для хранения и обработки информации какой-либо предметной области. База данных - важнейший компонент любой информационной системы. Хорошо структурированная информация в базе данных позволяет не только беспроблемно эксплуатировать систему и выполнять ее текущее обслуживание, но и модифицировать и развивать ее при модернизации предприятия и изменении информационных потоков, законодательства и форм отчетности.
В настоящее время в эксплуатации на крупных предприятиях находятся комплексные ИС управления предприятиями (КИС, корпоративные системы, ERP-системы), такие как R/3 фирмы SAP, Oracle E-Business Suite, BaanERP. Среди российских разработок приближаются по функциональности к системам класса ERP "Галактика", "Флагман", "Парус".
По данным аналитической компании IDC за 2004 г., объем российского рынка интегрированных систем управления предприятием (ИСУП) вырос на 52,8% и достиг 195 млн. долл. Уже третий год подряд темпы его роста превышают аналогичный показатель ИТ отрасли в целом (1.1).
Таблица 1.1. Объем российского рынка интегрированных систем управления предприятием в 2004 г. |
|
Название компании |
Доля (%) |
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-системы могут устанавливаться и функционировать на различных операционных системах и серверах баз данных (многоплатформенные системы). База данных подобных систем состоит из нескольких тысяч таблиц (BaanERP 5.0с - более 2500 таблиц информации по одному предприятию).
Любая сложная система для обеспечения ее надежного функционирования строится как иерархическая система, состоящая из отдельных подсистем и модулей, которые взаимодействуют между собой и используют общую базу данных.
На рис. 1.2 показан полный состав система BaanERP версии 5.0с (меню администратора системы) и состав модулей подсистемы "Производство".
Рис. 1.2. Подсистемы и модули BaanERP 5.0c
На рис. 1.3 приведена схема подсистем и модулей КИС "Флагман".
Рис. 1.3. Схема подсистем и модулей КИС "Флагман"
Понимание принципов разработки, организации и функционирования подобных систем, способов хранения и обработки информации необходимо каждому современному специалисту.
При описании информационной системы предполагается, что она содержит два типа сущностей: операционные сущности, которые выполняют какую-либо обработку (некоторый аналог программы), и пассивные сущности, которые хранят информацию, доступную для пополнения, изменения, поиска, чтения (база данных).
При проектировании сложных информационных систем используется метод декомпозиции - система разбивается на составные части, которые связаны, взаимодействуют друг с другом и образуют иерархическую структуру. Иерархический характер сложных систем хорошо согласуется с принципом групповой разработки. В этом случае деятельность каждого участника проекта ограничивается соответствующим иерархическим уровнем.
Классический подход к разработке сложных систем представляет собой структурное проектирование, при котором осуществляется алгоритмическая декомпозиция системы по методу "сверху вниз". Именно в этом случае можно построить хорошо функционирующую систему с общей базой данных, согласованными форматами использования и обработки информации на всех участках, с оптимальным взаимодействием всех подсистем.
Исторически сложилось так, что некоторые системы разрабатывались по методу "снизу вверх": вначале создавались отдельные автоматизированные рабочие места (АРМы), затем предпринимались попытки объединения их в единую информационную систему. Подобные разработки для крупных систем не могут быть успешны.
При создании проекта информационной системы для проектирования ее базы данных следует определить:
-
объекты информационной системы (сущности в концептуальной модели);
-
их свойства (атрибуты);
-
взаимодействие объектов (связи) и информационные потоки внутри и между ними.
При этом очень важен анализ существующей практики реализации информационных процессов и нормативной информации (законов, постановлений правительства, отраслевых стандартов), определяющих необходимый объем и формат хранения и передачи информации. Если радикальной перестройки сложившегося информационного процесса не предвидится, следует учитывать имеющиеся формы хранения и обработки информации в виде журналов, ведомостей, таблиц и т.п. бумажных носителей.
Однако предварительно необходимо выполнить анализ возможности перехода на новые системы учета, хранения и обработки информации, возможно, исходя из имеющихся на рынке программных продуктов-аналогов, разработанных крупными информационными компаниями и частично или полностью соответствующими поставленной задаче.
Схема формирования информационной модели представлена на рис.1.4.
Рис. 1.4. Схема формирования информационной модели
Концептуальная модель (см. рис.1.4) - отображает информационные объекты, их свойства и связи между ними без указания способов физического хранения информации (модель предметной области, иногда ее также называют информационно-логической или инфологической моделью). Информационными объектами обычно являются сущности - обособленные объекты или события, информацию о которых необходимо сохранять, имеющие определенные наборы свойств - атрибутов.
Физическая модель - отражает все свойства (атрибуты) информационных объектов базы и связи между ними с учетом способа их хранения - используемой СУБД.
Внутренняя модель - база данных, соответствующая определенной физической модели.
Внешняя модель - комплекс программных и аппаратных средств для работы с базой данных, обеспечивающий процессы создания, хранения, редактирования, удаления и поиска информации, а также решающий задачи выполнения необходимых расчетов и создания выходных печатных форм.
Создание информационной системы ведется в несколько этапов, на каждом из которых конкретизируются и уточняются элементы разрабатываемой системы.
Существуют различные типы схем, иллюстрирующих жизненный цикл разработки ИС. На рис.1.5 показана каскадная схема с обратной связью.
Рис. 1.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- IDEF1X описывают приемы изображения компонентов ИС, связей между ними и построения модели данных ИС.
В стандарте IDEF0 функциональный блок графически изображается в виде прямоугольника (см. рис. 1.6) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта, название каждого функционального блока должно быть сформулировано в виде глагола в побудительном наклонении ("выполнять операцию", а не "выполнение операции"). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
-
верхняя сторона имеет значение "Управление" (Control);
-
левая сторона имеет значение "Вход" (Input);
-
правая сторона имеет значение "Выход" (Output);
-
нижняя сторона имеет значение "Механизм" (Mechanism).
Рис. 1.6. Функциональный блок по стандарту IDEF0
Принципы изображения функциональных моделей стандарта IDEF0 используют инструментальные средства моделирования (CASE-средства - Computer-Aided Software System Engineering), такие как BPwin фирмы Computer Associates и др.
В стандарте IDEF1 сущности и связи концептуальной модели изображаются, как показано на рис. 1.7.
Рис. 1.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-модель может включать в себя следующие аспекты;
-
Структурный аспект: Use-Case-диаграммы, идентифицирующие бизнес-процессы и бизнес-транзакции, их взаимосвязь, соподчиненность и взаимодействие; Package-диаграммы, описывающие структуру предметной области и иерархическую структуру организации.
-
Динамический аспект: Behavior-диаграммы (Activity, Statechart, Collaboration, Sequence), описывающие поведение (жизненный цикл) бизнес-процесcов в их взаимодействии во времени и в пространстве с привязкой к используемым ресурсам и получаемым результатам.
-
Статический аспект: 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-системами и т.д.
Система Together Designer Community Edition - средство создания диаграмм UML 2.0. Позволяет строить диаграммы прецедентов (диаграммы сценариев взаимодействия пользователя с продуктом с точки зрения пользователя); диаграммы последовательностей, описывающие порядок передачи сообщений от одних объектов к другим; диаграммы кооперации, описывающие взаимодействие объектов друг с другом, диаграммы деятельности, описывающие потоки работ и изменение состояний объектов, диаграммы развертывания. При необходимости может создаваться логическая модель данных, содержащая диаграммы "сущность-связь", на ее основе генерируется физическая модель данных для конкретной СУБД, выбранной для реализации проекта.
На этапе создания клиентского и серверного кода все современные средства UML-моделирования могут осуществлять генерацию кода на различных языках программирования.
В феврале 2006 г. Object Management Group, Inc. (OMG, http://www.omg.org) - международный консорциум по разработке спецификаций в компьютерной индустрии - опубликовал финальную версию языка моделирования бизнес-процессов BPML (Business Process Modeling Language - http://www.omg.org/cgi-bin/doc?dtc/2006-02-01).
Основные графические элементы языка показаны на рис. 1.8
Рис. 1.8. Фрагмент модели бизнес-процесса, изображенного по стандарту BPML
Одной из последних разработок в области моделирования предприятия является создание специального унифицированного языка моделирования UEML (Unified Enterprise Modeling Language). Разработка UEML - сетевой проект (IST-2001-34229), финансируемый Евросоюзом (см. http://athena.troux.com/akmii/Default.aspx?WebID=249).
Проект UEML включает создание:
-
общего, визуального, базированного на шаблонах языка для коммерческих инструментальных средств моделирования предприятий и программных систем класса workflow;
-
стандартизованных, независимых от инструментов механизмов передачи моделей между проектами;
-
репозитория моделей предприятий.
Данный проект осуществляется в соответствии с международными стандартами:
-
ISO 14258 Rules and Guidelines for Enterprise Models (Правила и руководящие принципы для моделей предприятия);
-
ISO 15704 Requirements for enterprise-reference architectures and methodologies (Требования и методологии по описанию архитектуры предприятия).
Инструментальные средства моделирования предприятий, поддерживающие язык UEML, Metis (Computas), e-MAGIM (GraiSoft), MOzGO (IPK) и др.
В нашей стране в списке действующих ГОСТов по разработке автоматизированных систем (по данным Стандартинформ 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 Disigner, ERWin Data Modeler и др. Данные системы применяются при описании модели данных стандарт IDEF1X и позволяют генерировать программный код на языках SQL, VBScript, JScript, либо работать с другими технологиями для переноса физической модели в реальные СУБД, которыми могут быть Oracle, Microsoft SQL Server, IBM DB2, Informix, Microsoft Access и др.
На рис. 1.9 приведена схема, показывающая взаимосвязь основных терминов в области проектирования баз данных и работы с ними.
Рис. 1.9. Взаимосвязь основных терминов в области проектирования баз данных и работы с ними
Выбор системы для разработки приложений, работающих с базой данных, сложное и ответственное решение. Такую возможность имеют универсальные системы программирования: Visual C++ и C#, Delphi, Visual Basic и др. Однако специализированные языки программирования в составе СУБД располагают огромным количеством процедур и функций для работы с базами данных, специальными библиотеками, механизмами для ускорения работы с большими базами данных. В связи с повсеместным распространением Интранета, Экстранета и Интернета, многие системы имеют возможность создания трехуровневой сервис-ориентированной архитектуры Web-приложений для работы с базами данных.
В качестве аппаратных средств наиболее часто используются компьютеры на базе процессоров Intel с операционной системой Microsoft Windows (NT, 2000, XP), локальная сеть обычно строится с использованием возможностей этой ОС, файловый сервер и сервер баз данных может использовать ОС Microsoft Windows NT, 2000, Server 2003 либо другую операционную систему для выделенных серверов (например, Unix или NetWare).
2. Лекция: Принципы организации баз данных
Разобраны принципы классификации баз данных. Наибольшее внимание уделяется реляционным базам данных как основным в настоящее время. Рассмотрены некоторые теоретические вопросы реляционной теории. Цель: получение знаний по классификации баз данных, кратких сведений по теории реляционных баз данных.