Дисциплина «Базы данных» Лекция 2 Прикладная информатика в экономике Кафедра ИС
Информационная система – организационно упорядоченная совокупность документов и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы (Федеральный закон “Об информации, информатизации и защите информации”). Информационная система – это система, состоящая из следующих компонентов: информационная база; концептуальная схема; информационный процессор. ( ГОСТ 34.320-96 ИТ. Система стандартов по базам данных).
Жизненный цикл системы (типовая модель ЖЦ системы) начинается с концепции идеи системы или потребности в ней, охватывая разработку, создание, эксплуатацию и сопровождение системы, и заканчивается снятием системы с эксплуатации (утилизацией). Жизненный цикл системы разделяют на стадии (этапы): определение потребностей; исследование и описание основных концепций; демонстрация и аттестация основных концепций; проектирование ( в т.ч. проектирование БД ) и разработка ; создание и производство; распространение и продажа; эксплуатация; сопровождение и поддержка; снятие с эксплуатации (утилизация). (ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207-99 Процессы жизненного цикла программных средств)
При создании информационной системы требуется как согласование задач (функций), так и согласование данных ( построение функциональной модели, отвечающей на вопрос "Что должна делать ИС", и построение модели данных, отвечающей на вопрос "Как должна работать ИС"). При этом формулируются основные требования к организации данных ( интеграция данных, максимально возможная независимость данных от прикладных программ ), выполнение которых приводит к созданию единого для всех задач блока данных – базы данных (БД) и разработке одной управляющей программы для манипулирования данными на физическом уровне – системе управления базой данных (СУБД).
В широком смысле слова, БД - совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. База данных ( database ) – совокупность взаимосвязанных данных, организованных в соответствии со схемой базы данных таким образом, чтобы с ними мог работать пользователь ( ГОСТ 34.321-96 (ИТ. Система стандартов по базам данных. Эталонная модель управления данными).
База данных, являясь фундаментальным компонентом ИС и функционируя внутри сложной ИС, обладает собственным жизненным циклом ( Database Life Cycle – DBLC ), состоящим из 6 этапов: - этап начальной разработки ; - проектирование базы данных; - реализация и загрузка; - тестирование и оценка; - функционирование; сопровождение и развитие (Роб П., Коронел К. Системы баз данных).
Этап начальной разработки предполагает проведение обследования предметной области и включает: - анализ деятельности компании, - постановку задачи и определение ограничений, определение целей БД, - определение сферы действия и границ возможностей.
Определения: Под предметной областью (ПрО) будем понимать элементы материальной системы, информация о которых хранится и обрабатывается в ИС, т.е. под предметной областью (ПрО) принято понимать часть реального мира, подлежащего изучению для организации управления и в конечном счете автоматизации (например, предприятие, вуз и т.д.). Типичная предметная область состоит из реальных или абстрактных объектов, которые являются сущностями. Сущность – любой конкретный или абстрактный объект, включая связи между объектами.
Анализ деятельности компании предполагает: осуществление сбора информации через анкетирование, сбор документов, интервьюирование.
Постановка задачи и определение ограничений предполагает четкое определение точки зрения, с которой будет моделироваться рассматриваемая предметная область, структурирование выявленных проблем и требований пользователей, определение рамок проекта (Что входит? Что не входит?); определение цели БД ; обозначение сферы действия (уровень решаемых задач: все предприятие, одно, несколько подразделений, одна, несколько функций одного подразделения) определение границы возможностей разрабатываемой БД (ресурсы, оборудование, программное обеспечение).
Одним из результатов этапа начальной разработки является построение полной непротиворечивой функциональной (процессной) модели, например, DFD ( Data Flow Diagramm ) – диаграммы потоков данных, отвечающей на вопрос: Что должна делать разрабатываемая БД?
Этап проектирования БД – процесс создания проекта БД, предназначенной для поддержки функционирования предприятия и способствующей достижению его целей. Проектирование БД, в свою очередь, состоит из следующих этапов: Концептуальное (инфологическое) проектирование Выбор программного обеспечения СУБД Логическое проектирование Физическое проектирование
Концептуальное проектирование – процесс создания концептуальной (информационной) модели данных предприятия (абстрактной структуры БД) посредством моделирования данных без учета физических условий реализации (оборудования и программного обеспечения: СУБД, языка программирования). Иначе, концептуальное проектирование - представление БД, включающее определение типов важнейших сущностей и существующих между ними связей, отражающее представление отдельных пользователей о предметной области.
Правило необходимого минимума информации: Все, что необходимо, здесь есть и все, что здесь есть, необходимо Необходимо убедиться, что концептуальная модель включает все нужные данные, и что все данные, имеющиеся в модели, действительно нужны. При этом, важно не свести проект к чрезмерному упрощению, рассматривать его в развитии, т.е с учетом последующих модификаций и добавлений решаемых задач. Одним из результатов этапа концептуального проектирования является построение модели данных «сущность-связь» ERD ( Entity Relationship Diagramm ).
2. Выбор программного обеспечения СУБД (расширение масштабов предприятия или замена существующей системы). Цель этапа в выборе системы управления базой данных, которая удовлетворяет текущим и будущим требованиям организации, а также обладает оптимальной стоимостью, включая расходы на приобретение СУБД и любого другого дополнительного программного/аппаратного обеспечения, расходы на замену системы и переобучение персонала.
3. Логическое проектирование Логическое проектирование используется для перенесения концептуального проекта на внутреннюю модель выбранной СУБД ( Access, SQL Server, Oracle и т.д.) с учетом выбранного типа модели данных (сетевая, иерархическая или реляционная). Для реляционных СУБД логическое проектирование включает в себя проектирование таблиц, индексов, представлений, авторизации доступа и т.д. Логическое проектирование зависит от особенностей СУБД, но не зависит от оборудования.
4. Физическое проектирование На этапе физического проектирования, которое является чисто технической задачей, определяются специфические структуры хранения и пути доступа, что естественно зависит от конкретного оборудования.
Case - технологии ( Computed Aided System Engineering ) значительно ускорили и упростили процесс разработки БД. Case - технологии – совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанные комплексом взаимоувязанных средств автоматизации. Case – инструментарий системных аналитиков, разработчиков, программистов, автоматизирующий процесс проектирования и разработки ПО.
Основной целью Case является отделение процесса проектирования от процесса программирования. Современные Case-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл системы.
Case- средства фирмы CA (Computer Associates): AllFusion Process Modeler (BPwin) – средство функционального моделирования и моделирования поведения системы, поддерживающее нотации IDEF0, DFD и IDEF3 – этап начальной разработки БД; AllFusion Erwin Data Modeler (ERwin) – средство проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (на языке SQL) для наиболее распространенных СУБД. Примечание: Программный продукт фирмы Microsoft – Microsoft Visio реализует те же стандарты и нотации и также может быть использован для проектирования БД.
Этап реализации и загрузки данных Реализация и загрузка данных предполагает выполнение следующих этапов: - установки СУБД; - создание БД; загрузка или конвертирование данных. Реализация предполагает физическое воплощение разработанной БД в среде конкретной СУБД. Примечание: Case -средства AllFusion Erwin Data Modeler ( ERwin ) осуществляет генерацию схемы БД в выбранную СУБД.
Конвертирование и загрузка данных предусматривает перенос любых существующих данных в новую БД с учетом преобразования в требуемый формат. В процессе реализации и загрузки данных необходимо обратить внимание на производительность, безопасность, создание резервных копий и восстановление, целостность, стандарты компании и управление параллельным выполнением.
Этап тестирования и оценки После того, как данные загружены в БД, администратор БД тестирует и настраивает БД на оптимальную производительность, целостность (возможное появление ошибок в результате операций манипулирования данными), параллельный доступ и ограничения безопасности. Этап тестирования и оценки происходит параллельно с программированием приложений или созданием прототипов (создание рабочей модели приложения БД). Этап функционирования или эксплуатации является отправной точкой процесса развития системы, предполагает наблюдение за системой и поддержку ее нормального функционирования .
Этап сопровождения и развития Администратор БД должен быть готов к процедурам, связанным с постоянным обслуживанием БД: - профилактическое обслуживание (резервное копирование); - корректирующее обслуживание (восстановление); - адаптивное обслуживание (повышение производительности, добавление сущностей и атрибутов); - назначение прав доступа и их обслуживание для новых и прежних пользователей; - дополнительные формы отчетности и новые форматы запросов с учетом возможных изменений требований пользователя к информации и т.д.
Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла (ЖЦ). Технологии проектирования – инструментальные средства, поддерживающие сам процесс проектирования. В настоящее время можно выделить два основных методологических подхода к проектированию: структурный и объектно-ориентированный подходы.
Структурным анализом (СА) принято называть метод исследования системы, изучение которой начинается с ее общего обзора, последующей детализации, созданием иерархической структуры с достаточным числом уровней. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов.
В качестве двух базовых принципов структурного анализа используются следующие: принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
В структурном анализе используются в основном три группы средств моделирования : - диаграммы, иллюстрирующие функции, которые должна выполнять система, и связи между этими функциями – для этой цели чаще всего используются DFD и SADT ( IDEF 0). SADT (Structured Analysis and Design Technique ) функциональная модель – основное средство моделирования функциональных требований проектируемой системы (функциональная модель деятельности); DFD (Data Flow Diagrams) - диаграммы потоков данных устанавливают связь источников информации с потребителями, выделяют логические функции (процессы) преобразования информации, определяют группы элементов данных и их хранилища (базы данных);
диаграммы, моделирующие данные и их взаимосвязи (предназначены для разработки моделей данных или инфологической модели предметной области) – для этой цели используются диаграммы «сущность-связь» ERD ( Entity - Relationship Diagrams ); диаграмма переходов состояний, моделирующие зависящее от времени поведение системы - STD (State Transition Diagrams).
Применение средств СА позволяет построить модель требований (логическую модель), состоящую из взаимосвязанных диаграмм ( DFD, ERD, STD ), спецификации процессов, текстов и словаря данных. Модель требований описывает, что должна делать проектируемая система без ссылок на то, как это делается. Через выделение основного DFD процесса может осуществляться его декомпозиция.
Логическая DFD модель показывает внешние по отношению к системе источники и адресаты данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицируют хранилища (накопители) данных, к которым осуществляется доступ.
Каждая логическая функция (процесс) м.б. детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестанет быть полезной, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации) 2. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных.
3. Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. 4. В случае наличия реального времени DFD дополняется средствами описания зависящего от времени поведения системы, раскрывающегося с помощью STD.
Диаграммы потоков данных (DFD) являются средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Примечание: Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота.
Название символа и назначение Обозначение (нотация Гейна-Сарсона) Поток данных Процесс Хранилище (накопитель) данных Внешняя сущность
Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Для моделирования информации, которая движется в одном направлении, обрабатывается и возвращается назад к источнику, можно использовать либо два различных потока, либо один - двунаправленный.
Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым его именем. Оно должно содержать глагол в неопределенной форме с последующим дополнением (например, вычислить максимальную высоту). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. В целях получения уникального индекса процесса во всей модели этот номер нужно использовать совместно с номером диаграммы (А1.1).
Хранилище (накопитель) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке.
Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда структура потока данных, входящего или выходящего в/из хранилища, соответствует структуре хранилища, имя потока данных может быть опущено, т.е не отражаться на диаграмме. В общем случае хранилище является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью.
Внешняя сущность представляет сущность вне контекста системы (за границами системы), являющуюся источником или приемником системных данных. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке. Имя внешней сущности должно содержать существительное, например, склад товаров.
Важную специфическую роль в модели играет специальный вид DFD - контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а также единственный процесс, изображающий систему в целом. Основная цель данной диаграммы состоит в установлении границ анализируемой системы. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса.
DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме. На данной диаграмме помимо процессов и потоков данных, их связывающих, добавлены хранилища с целью отражения данных, которые запоминаются по мере выполнения тех или иных событий.
Каждый из процессов может быть декомпозирован в DFD нижнего уровня. Декомпозиция продолжается до тех пор, пока процессы не будут представлять элементарные действия по работе с данными системы, которые могут быть эффективно описаны с помощью коротких (до одной страницы) миниспецификаций обработки ( спецификаций процессов ). Таким образом, строится иерархия DFD с контекстной диаграммой в корне дерева.
Спасибо за внимание
