Лекция1_ЖЦ_БД_1.09.2021 PDF

Введение в базы данных Лекция № 1 Дисциплина «Базы данных»  Вопросы 1. Что такое информация? 2. Что такое данные? 3. Что такое модель данных? 4. Что такое база данных? 5. Что такое информационная система? ...

Введение в базы данных Лекция № 1 Дисциплина «Базы данных»  Вопросы 1. Что такое информация? 2. Что такое данные? 3. Что такое модель данных? 4. Что такое база данных? 5. Что такое информационная система?  Вопросы для рассмотрения Понятие информационной системы (ИС). Понятие автоматизированной ИС. Жизненный цикл системы (ЖЦ). Понятие базы данных (БД). Жизненный цикл БД: - этап начальной разработки; - проектирование базы данных; - реализация и загрузка; - тестирование и оценка; - функционирование; - сопровождение и развитие. Понятие структурного анализа (СА) и проектирования. Средства моделирования в СА. Автоматизированные средства анализа и проектирования (Case – технологии). Диаграммы потоков данных (DFD)  Основные понятия и определения Информационная система – организационно упорядоченная совокупность документов и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы (Федеральный закон “Об информации, информатизации и защите информации”). Информационная система – это система, состоящая из следующих компонентов: информационная база; концептуальная схема; информационный процессор. (ГОСТ 34.320-96 ИТ. Система стандартов по базам данных). Информационная система (ИС) - взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели.  Основные понятия и определения Автоматизированная система: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций (ГОСТ 34.003-90 Комплекс стандартов на автоматизированные системы ). Автоматизированная система представляет собой организационно-техническую систему, обеспечивающую выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т.д.) или их сочетаниях. (РД 50-680-88 «Руководящий документ по стандартизации»). Автоматизированная информационная система – это искусственно созданная человеком взаимосвязанная совокупность средств (в том числе и компьютерных), методов и персонала, используемых для получения, хранения, обработки, манипулирования и выдачи информации в интересах достижения поставленной цели.  Жизненный цикл системы Жизненный цикл системы (типовая модель ЖЦ системы) начинается с концепции идеи системы или потребности в ней, охватывая разработку, создание, эксплуатацию и сопровождение системы, и заканчивается снятием системы с эксплуатации (утилизацией). Жизненный цикл системы разделяют на стадии (этапы): определение потребностей; исследование и описание основных концепций; демонстрация и аттестация основных концепций; проектирование (в т.ч. проектирование БД) и разработка; создание и производство; распространение и продажа; эксплуатация; сопровождение и поддержка; снятие с эксплуатации (утилизация). (ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207-99 Процессы жизненного цикла программных средств)  Базы данных При создании информационной системы требуется как согласование задач (функций), так и согласование данных (построение функциональной модели, отвечающей на вопрос "Что должна делать ИС", и построение модели данных, отвечающей на вопрос "Как должна работать ИС"). При этом формулируются основные требования к организации данных (интеграция данных, максимально возможная независимость данных от прикладных программ), выполнение которых приводит к созданию единого для всех задач блока данных – базы данных (БД) и разработке одной управляющей программы для манипулирования данными на физическом уровне – системе управления базой данных (СУБД).  Этапы жизненного цикла БД В широком смысле слова, БД - совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. База данных (database) – совокупность взаимосвязанных данных, организованных в соответствии со схемой базы данных таким образом, чтобы с ними мог работать пользователь (ГОСТ 34.321-96 (ИТ. Система стандартов по базам данных. Эталонная модель управления данными). База данных, являясь фундаментальным компонентом ИС и функционируя внутри сложной ИС, обладает собственным жизненным циклом (Database Life Cycle – DBLC), состоящим из 6 этапов: - этап начальной разработки; - проектирование базы данных; - реализация и загрузка; - тестирование и оценка; - функционирование; - сопровождение и развитие (Роб П., Коронел К. Системы баз данных).  Этапы жизненного цикла БД Этап начальной разработки Этап начальной разработки предполагает проведение обследования предметной области и включает: - анализ деятельности компании, - постановку задачи и определение ограничений, определение целей БД, - определение сферы действия и границ возможностей. Определения: Под предметной областью (ПрО) будем понимать элементы материальной системы, информация о которых хранится и обрабатывается в ИС. Иными словами, под предметной областью (ПрО) принято понимать часть реального мира, подлежащего изучению для организации управления и в конечном счете автоматизации, например, предприятие, вуз и т.д. Типичная предметная область состоит из реальных или абстрактных объектов, которые являются сущностями. Сущность – любой конкретный или абстрактный объект, включая связи между объектами.  Этапы жизненного цикла БД Этап начальной разработки Анализ деятельности компании предполагает осуществление сбора информации через анкетирование, сбор документов, интервьюирование. Постановка задачи и определение ограничений предполагает четкое определение точки зрения, с которой будет моделироваться рассматриваемая предметная область, структурирование выявленных проблем и требований пользователей, определение рамок проекта (Что входит? Что не входит?); определение цели БД; обозначение сферы действия (уровень решаемых задач: все предприятие, одно, несколько подразделений, одна, несколько функций одного подразделения) и определение границы возможностей разрабатываемой БД (ресурсы, оборудование, программное обеспечение). Одним из результатов этапа начальной разработки является построение полной непротиворечивой функциональной (процессной) модели, например, DFD (Data Flow Diagramm) – диаграммы потоков данных, отвечающей на вопрос: Что должна делать разрабатываемая БД?  Этапы жизненного цикла БД Этап проектирования БД Этап проектирования БД – процесс создания проекта БД, предназначенной для поддержки функционирования предприятия и способствующей достижению его целей. Проектирование БД, в свою очередь, состоит из следующих этапов: Концептуальное (инфологическое) проектирование Логическое проектирование Физическое проектирование  Этапы жизненного цикла БД Этап проектирования БД 1. Концептуальное проектирование – процесс создания концептуальной (информационной) модели данных предприятия (абстрактной структуры БД) посредством моделирования данных без учета физических условий реализации (оборудования и программного обеспечения: СУБД, языка программирования). Иначе, концептуальное проектирование - представление БД, включающее определение типов важнейших сущностей и существующих между ними связей, отражающее представление отдельных пользователей о предметной области. Правило необходимого минимума информации: Все, что необходимо, здесь есть и все, что здесь есть, необходимо Необходимо убедиться, что концептуальная модель включает все нужные данные, и что все данные, имеющиеся в модели, действительно нужны. При этом, важно не свести проект к чрезмерному упрощению, рассматривать его в развитии, т.е с учетом последующих модификаций и добавлений решаемых задач. Одним из результатов этапа концептуального проектирования является построение модели данных «сущность-связь» ERD (Entity Relationship Diagramm).  Этапы жизненного цикла БД Этап проектирования БД 2. Логическое проектирование Логическое проектирование используется для перенесения концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (сетевая, иерархическая или реляционная). Для реляционных СУБД предполагается определение набора отношений, проверка модели с помощью правил нормализации отношений, определение требований поддержки целостности данных, проверка модели в отношении транзакций пользователей. 3. Физическое проектирование Физическое проектирование базы данных предполагает принятие разработчиком окончательного решения о способах реализации создаваемой БД. Физическое проектирование проводится с учетом всех особенностей выбранной целевой СУБД (Access, SQL Server, Oracle и т.д.) Для реляционных СУБД предполагается проектирование таблиц, индексов, представлений, авторизации доступа и т.д.  Автоматизированные средства анализа и проектирования (Case – технологии) Case - технологии (Computed Aided System Engineering) значительно ускорили и упростили процесс разработки БД. Case - технологии – совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанные комплексом взаимоувязанных средств автоматизации. 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 – Data Flow Diagramming) на этапе начальной разработки БД Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла (ЖЦ). Технологии проектирования – инструментальные средства, поддерживающие сам процесс проектирования. В настоящее время можно выделить два основных методологических подхода к проектированию: структурный и объектно-ориентированный подходы.  Структурный анализ Структурным анализом (СА) принято называть метод исследования системы, изучение которой начинается с ее общего обзора, последующей детализации, созданием иерархической структуры с достаточным числом уровней. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов структурного анализа используются следующие: принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.  Структурный анализ В структурном анализе используются в основном три группы средств моделирования: 1) диаграммы, иллюстрирующие функции, которые должна выполнять система, и связи между этими функциями – для этой цели чаще всего используются DFD и SADT(IDEF0). SADT (Structured Analysis and Design Technique) функциональная модель – основное средство моделирования функциональных требований проектируемой системы (функциональная модель деятельности); DFD (Data Flow Diagrams) - диаграммы потоков данных устанавливают связь источников информации с потребителями, выделяют логические функции (процессы) преобразования информации, определяют группы элементов данных и их хранилища (базы данных); 2) диаграммы, моделирующие данные и их взаимосвязи (предназначены для разработки моделей данных или инфологической модели предметной области) – для этой цели используются диаграммы «сущность-связь» ERD (Entity-Relationship Diagrams); 3) диаграмма переходов состояний, моделирующие зависящее от времени поведение системы - STD (State Transition Diagrams).  Компоненты логической модели Применение средств СА позволяет построить модель требований (логическую модель), состоящую из взаимосвязанных диаграмм (DFD, ERD, STD), спецификации процессов, текстов и словаря данных. Модель требований описывает, что должна делать проектируемая система без ссылок на то, как это делается. Через выделение основного DFD процесса может осуществляться его декомпозиция. Логическая DFD показывает внешние по отношению к системе источники и адресаты данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицируют хранилища (накопители) данных, к которым осуществляется доступ. Компоненты логической модели 1. Каждая логическая функция (процесс) м.б. детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестанет быть полезной, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации) 2. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. 3. Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. 4. В случае наличия реального времени DFD дополняется средствами описания зависящего от времени поведения системы, раскрывающегося с помощью STD.  Диаграммы потоков данных Диаграммы потоков данных (DFD) являются средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Примечание: Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота.  Основные символы DFD и их графическое обозначение заяв ление сп Название символа и назначение 1 Обозначение (нотация Гейна-Сарсона) заяв ление 2 с Поток данных доку менты 1 ИМЯ ПРОЦ ЕСС А заяв ление списки на экзамен 1 Процесс экзаменационный лис т 3 ИМЯ ВНЕШ ПРОЦНЕЙ ЕСС А 2 ИМЯ доку менты атес СУЩН ОС ТИ 2 ИМЯ ПРОЦЕССА Хранилище (накопитель) доку менты 2 ИМЯ ХРАН ИЛИЩА э кзаменационный лис т 3 данных ИМЯ ВНЕШ НЕЙ СУ ЩН ОС ТИ 3 NODE: TITLE: имя ВнешняяA0 сущность экзаменационный лист 3 ИМЯ ВНЕШНЕЙ ИМЯ 2 ХРАН ИЛИЩА СУЩНОСТИ NODE: TITLE: имя A0 ИМЯ 2 ХРАНИЛИЩА Контекстная диаграмма DFD по учебной задаче «Автосалон» USED AT: AUTHOR: tutor DATE: 16.02.2007 WORKING READER DATE CONTEXT: PROJECT: avto REV: 11.03.2009 DRAFT RECOMMENDED TOP NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION 1 Клиент паспорт 2 Менеджер по информац ия об авто продажам из ПТС A0 заказ отчет по продажам Оформление сделки по продаже авто справка-счет ПТС договор купли-продажи пакет сопроводительных Цель: увеличение числа продаж документов Точка зрения: менеджера по продажам NODE: TITLE: Оформление сделки по продаже авто NUMBER: A-0  Диаграмма декомпозиции DFD по учебной задаче «Автосалон» USED AT: AUTHOR: tutor DATE: 16.02.2007 WORKING READER DATE CONTEXT: PROJECT: avto REV: 11.03.2009 DRAFT RECOMMENDED NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION A-0 заказ оформленный (авто в заказ наличии оригинал заказа заказ нет) A1 D1 заказ Регистрация заказа информац ия о заказе договор купли-продажи заказ (авто в A2 договор наличии ) D2 договор паспорт Заключение инф. о договора продавце купли-продажи инф. из документ об договора ПТС оплате (чек) информац ия A3 о клиенте пакет Оформление пакета сопроводительных сопроводительной документов D3 Клиент документации Продавец D6 информац ия информац ия Справка- об авто об авто D5 счет справка-счет справка-счет информац ия о сделке отчет по информац ия об информац ия о заказе A4 продажам инф. из договора авто из ПТС D4 авто Оформление информац ия о клиенте инф. о продавц е отчетности информац ия об авто NODE: TITLE: Оформление сделки по продаже авто NUMBER: A0  Диаграммы потоков данных Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Для моделирования информации, которая движется в одном направлении, обрабатывается и возвращается назад к источнику, можно использовать либо два различных потока, либо один - двунаправленный. Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым его именем. Оно должно содержать глагол в неопределенной форме с последующим дополнением (например, вычислить максимальную высоту). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. В целях получения уникального индекса процесса во всей модели этот номер нужно использовать совместно с номером диаграммы (А1.1).  Диаграммы потоков данных Хранилище (накопитель) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда структура потока данных, входящего или выходящего в/из хранилища, соответствует структуре хранилища, имя потока данных может быть опущено, т.е не отражаться на диаграмме. В общем случае хранилище является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью. Внешняя сущность представляет сущность вне контекста системы (за границами системы), являющуюся источником или приемником системных данных. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке. Имя внешней сущности должно содержать существительное, например, склад товаров.  Диаграммы потоков данных Важную специфическую роль в модели играет специальный вид DFD - контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а также единственный процесс, изображающий систему в целом. Основная цель данной диаграммы состоит в установлении границ анализируемой системы. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса.  Спасибо за внимание!