бд полный курс. Информация, данные, информационные системы Информация как социальный ресурс
 Скачать 1.56 Mb.
|
|
Как видно из таблицы, не существует единой модели, в рамках которой можно представить весь жизненный цикл системы. Так, стадия анализа предметной области системы представляется с помощью трех типов моделей: модели данных, которые описывают внутренние, логические взаимоотношения между данными в системе; модели процессов, которые описывают процессы обработки или преобразования данных в системе; модели состояний, которые описывают поведение или отклики системы на события. Несмотря на то, что каждая из диаграмм может быть представлена с помощью широкого спектра нотаций, все они в рамках определенной диаграммы имеют общие основные черты. Ниже приведены правила, которыми должен руководствоваться проектировщик в ходе формальной проверки правильности представленных моделей. На диаграммах "сущность-связь" должны быть представлены сущности, связи, степени связи, классы принадлежности сущности, неопределенные связи, супертипы/подтипы сущности. При этом каждая сущность и отношение должны быть поименованы и занесены в словарь данных; каждая сущность может появиться на диаграмме только один раз; каждая сущность должна вступать в отношение (отсутствие "висящих" сущностей), и каждое отношение должно иметь сущности (отсутствие "висящих" отношений). Поэтому проектировщик базы данных должен проконтролировать, чтобы связь между сущностями осуществлялась через точно указанные атрибуты, которые, вероятнее всего, будут определять уникальный ключ связи. Проектировщик базы данных должен проконтролировать, чтобы в информационной модели предметной области для каждого атрибута сущностей был определен домен. Следует понимать, что определение домена, даваемое аналитиками, носит самый общий характер (число, текст, дата, графика и т.д.), и будет далее уточнено при проектировании. На этом этапе важно, чтобы домен был определен. На диаграммах модели бизнес-процессов должны быть представлены работы, вход, выход, управление и механизмы. При этом все элементы должны быть поименованы; все работы должны получаться путем функциональной декомпозиции некоторой более крупной работы; для каждой работы должно быть задано управление. На диаграммах потока данных должны быть представлены внешние сущности (источники и потребители данных), процессы обработки данных, конкурирующие процессы, хранилища данных, потоки данных, указатели ветвления процессов. При этом все процессы должны быть пронумерованы: исходный (начальный) процесс должен иметь номер 0; процессы более низких уровней - 1.1, 1.2, и т.д.; 1.1.1, 1.1.2, и т.д. На диаграммах жизненного цикла сущностей и диаграммах состояний должны быть представлены состояния, переходы и внешние переходы. При этом на диаграммах должно присутствовать начальное состояние, из которого получаются все остальные состояния. В конечное состояние можно попасть из любого состояния. Запрещается одновременно переход в два состояния; каждый переход имеет условие и действие, которые указываются рядом с переходом. Таким образом, формальные процедуры проверки нацелены на проверку таких аспектов анализа, как: наличие у каждой сущности уникального идентификатора; наличие функции, создающей экземпляры сущности; наличие хотя бы одной функции, которая ссылается на сущность, и т.п. В основе формальной проверки лежат такие прагматичные соображения, как: зачем создавать сущность, если она никогда не используется или если к ней никогда не будет произведен доступ; зачем создавать сущность, которую нельзя однозначно идентифицировать и т.п. Следует иметь в виду, что большинство современных CASE -средств, используемых при анализе предметной области и проектировании баз данных, содержат ряд возможностей по автоматизации описанных формальных процедур. Формальные процедуры проверки качества моделей позволяют проектировщику базы данных убедиться в их "формальной" достоверности, но не позволяют оценить, насколько они адекватно отражают реальную ситуацию внешнего мира в рамках предметной области. Поэтому часто требуется прибегать к неформальным процедурам проверки результатов моделирования предметной области. Неформальные процедуры заключаются в проведении личных бесед с аналитиками, постановщиками задач, конечными пользователями и руководителями всех автоматизируемых подразделений, проведении семинаров и совещаний всех участников проекта, а также в изучении материалов анализа предметной области. В ходе неформальных процедур могут быть выявлены существенные ошибки (например, потеря сущности предметной области), которые могут привести к пересмотру некоторых результатов проектирования и реализации баз данных, что в конечном счете может стать причиной срыва запланированных сроков выполнения проекта1 По окончании проверки качества моделей предметной области составляется список замечаний. Все вопросы, возникшие в ходе проведения контроля качества результатов анализа предметной области, разрешаются проектировщиками совместно с аналитиками и руководителем ИТ-проекта. Результаты проверки доводятся до сведения руководителя проекта. Введение Настоящий курс лекций построен таким образом, чтобы материал этой лекции изучался дважды: первый раз с целью установочного характера, чтобы была понятна логика следующих лекций; второй раз - после последней лекции с целью ответа на вопросы и задачи теста. Что такое проектирование базы данных Значительная часть проектов в области информационных технологий (далее ИТ-проектов) направлена на разработку и создание информационных систем, в рамках которых осуществляется обработка данных различной сложности. Целью таких проектов является разработка и создание информационной системы с базами данных. Практически во всех таких проектах решается задача проектирования баз данных определенного типа. Решение задачи проектирования повышает вероятность того, что разрабатываемая информационная система (далее - система) будет удовлетворять заданным функциональным и информационным требованиям с учетом заданных ограничений. Примеры функциональных требований: выдача отчетов по продажам по регионам; выдача отчетов по продажам по кварталам; автоматический расчет скидок на товары при увеличении объема закупаемой партии и т.п. Примеры ограничений: максимальное время, отпущенное на проект; количество денежных средств, которое можно на него потратить. Следует также учитывать технологические средства, доступные при реализации проекта, например требование реализации базы данных в архитектуре "файл-сервер". В эксплуатации база данных и ее окружение должны удовлетворять набору требований по ряду укрупненных (интегрированных) параметров, таких как: функциональность и адаптируемость; производительность обработки транзакций; пропускная способность; время реакции; безопасность. Это далеко не полный перечень параметров, по которым выставляются требования к базам данных, однако он содержит параметры, требования по которым выставляются наиболее часто. Такие параметры иногда находятся в противоречии друг к другу. Так, высокие требования по функциональности на данном конкретном оборудовании могут вступать в конфликт с высокими требованиями по производительности. Например, отчеты могут генерироваться в течение нескольких часов и снизить в это время реакции пользователей, работающих с системой в диалоговом режиме. Параметры, выражающие требования к базе данных, могут ранжироваться посредством присвоения приоритетов. Присвоение высшего приоритета требованию создать структуру данных для достижения системой максимально возможной производительности может привести к тому, что при проектировании базы данных требование обеспечить удобство работы определенной категории пользователей будет рассматриваться через призму производительности. Например, в системе бронирования авиабилетов в транснациональной авиакомпании время отклика на запрос не должно превышать 15-30 секунд. Поэтому, если это требование не будет удовлетворяться, то потребуется "разгрузить" приложение оператора. Таким образом, процесс проектирования базы данных заключается в достижении компромиссов между функциональными, информационными, аппаратными, архитектурными и технологическими требованиями к базе данных и строится на информированном принятии решений по структуре базы данных. Введем определение проектирования баз данных. Определение 1. Проектирование базы данных - это поиск способов удовлетворения функциональных требований средствами имеющейся компьютерной технологии с учетом заданных ограничений. Как правило, ИТ-проекты по созданию базы данных включают в себя следующие этапы: определение стратегии построения системы, анализ требований к базе данных, проектирование базы данных, реализация базы, тестирование и внедрение базы данных. Этап проектирования базы данных считается одним из самых сложных "размытых" этапов создания базы данных, который не имеет явно выраженного начала и окончания. По сравнению с анализом требований к базе данных или разработкой приложений, проектирование базы данных, по мнению многих ведущих специалистов, является плохо структурированной задачей. Если все этапы создания базы данных перекрываются друг с другом в своей последовательности, то этап проектирования перекрывается со всеми остальными этапами. Проектирование начинается с момента принятия стратегических решений и продолжается на этапах реализации и тестирования. Процесс проектирования базы данных охватывает несколько основных сфер. Проектирование объектов базы данных (таблицы, представления, индексы, триггеры, хранимые процедуры, функции, пакеты) для представления данных предметной области в базе данных. Проектирование интерфейса взаимодействия с базой данных (формы, отчеты и т.д.), т.е. проектирование приложений, которые будут сопровождать данные в базе данных и реализовывать вопросно-ответные отношения на этих данных. Проектирование баз данных под конкретную вычислительную среду или информационную технологию (архитектура "клиент-сервер", параллельные архитектуры, распределенная вычислительная среда). Проектирование баз данных под назначение системы (интеллектуальный анализ данных, OLAP, OLTP и т.д.). Отметим, что приложения работы с базой данных проектируются одновременно с физической схемой базы данных, а не отдельно! Зачастую вычислительная среда задается в качестве входных условий проектирования, но иногда проектирование следует проводить с учетом возможного перехода в будущем на другую аппаратную платформу или технологию. Внимание! Базы данных всегда проектируются под конкретное назначение системы. Техника проектирования баз данных может измениться в целом и в деталях в зависимости от назначения системы. Например, следует различать проектирование систем складирования данных и проектирование так называемых OLTP -систем, ориентируемых на оперативную обработку транзакций. В данном учебном курсе рассматривается проектирование баз данных в основном для OLTP -систем. Именно на таких системах исторически сложилась техника проектирования баз данных. Известно, что база данных: имеет свою внутреннюю архитектуру; имеет свое собственное лингвистическое содержание; действует в рамках некоторой внешней среды; имеет свои средства взаимодействия с внешней средой; функционирует на конкретной программно-аппаратной платформе; поддерживается в рамках определенных организационно-технологических мероприятий. Таким образом, база данных является сложным многокомпонентным объектом, объединяющим аппаратное обеспечение, программное обеспечение, информацию в виде данных и персонал. Основной задачей проектировщика базы данных является обоснованный выбор такой ее структуры, которая обеспечит согласованное взаимодействие всех ее компонентов согласно заданным функциональным требованиям в рамках заданных ограничений. В данном курсе мы не рассматриваем вопросы анализа предметной области. Эта задача предшествует проектированию базы данных, и решают ее аналитики. Однако проектировщик баз данных должен знать результаты выполнения этой задачи и уметь правильно интерпретировать их в ходе проектирования. Результаты анализа предметной области базы данных, а именно модели данных предметной области на семантическом уровне, являются исходными данными для решения задач проектирования базы данных. Поэтому проектировщик должен знать концепции, лежащие в основе моделирования данных предметной области, и конструкции, образующие совокупность этих моделей. иповая бизнес-модель процесса проектирования базы данных Процесс проектирования базы данных может быть представлен в виде модели бизнес-процессов. Обычно проектировщики не создают бизнес-модель процесса проектирования базы данных. А напрасно! Бизнес-модель процесса проектирования позволяет: отобразить субъективное мнение проектировщика баз данных на процесс проектирования конкретной базы данных; учесть особенности ИТ-проекта, в рамках которого проектируется база данных; достаточно быстро составить план проектирования конкретной базы данных; просчитать длительность проектных работ (создать временную модель проектирования). Рассмотрим типовую бизнес-модель процесса проектирования базы данных. На рис. 3.1 приведена контекстная диаграмма процесса проектирования базы данных.  Рис. 3.1. Контекстная диаграмма процесса проектирования базы данных Как видно из рисунка, на вход процесса проектирования базы данных подаются: информационная модель предметной области базы данных: диаграммы "сущность-связь" ( ER -диаграммы); функциональная модель предметной области базы данных: бизнес-модель процессов, диаграммы потока данных ( DF -диаграммы), диаграммы состояний, - диаграммы жизненных циклов сущностей, спецификации на системы (требования), бизнес-правила; общесистемные требования и ограничения; задачи обратного влияния. Могут быть представлены и другие документы. Примечание. Под задачами обратного влияния здесь понимается совокупность проблем, которые возникают в процессе разработки приложений базы данных, ее тестирования, опытной и промышленной эксплуатации и приводят к модификации физической модели базы данных. Примером такой задачи является настройка операторов SELECT с целью увеличения производительности выборки. На выходе процесса проектирования базы данных формируются следующие результаты: физическая модель базы данных, которая может быть преобразована в скрипт для создания базы данных; физическая база данных; спецификация модулей приложений базы данных; план тестирования базы данных. По требованию может быть разработана и другая документация. Продолжим функциональную декомпозицию процесса проектирования базы данных. На рис. 3.2 приведена диаграмма декомпозиции процесса проектирования базы данных первого уровня, отражающая основные наиболее крупные профессиональные задачи (этапы) проектирования базы данных. Внимание! В настоящем курсе рассматривается минимально необходимый, с точки зрения автора, набор задач, позволяющий спроектировать реляционную базу данных.  Рис. 3.2. Диаграмма декомпозиция процесса проектирования базы данных: первый уровень Такими задачами (этапами) являются: сбор и анализ входных данных; создание логической модели базы данных ; создание физической модели базы данных: внутренняя схема; создание физической модели базы данных: учет влияния транзакций ; создание серверного кода ; проектирование модулей приложений базы данных; контроль качества проектирования базы данных ; задачи обратного влияния. Сбор и анализ входных данных - это начальный этап проектирования, на котором осуществляется сбор и контроль качества результатов анализа предметной области базы данных, готовится план проектирования базы данных. Создание логической модели базы данных - это этап, на котором на основании информационной модели предметной области базы данных создается логическая структура базы данных, независимая от ее реализации. Создание физической модели базы данных: внутренняя схема - это этап, на котором на основании логической модели базы данных создается физическая структура базы данных, зависимая от ее реализации. На этом этапе выполняется преобразование отношений логической модели реляционной базы данных в команды создания объектов физической базы данных, в результате чего создается так называемая внутренняя схема базы данных. Дополнительно может быть создана так называемая внешняя схема базы данных, которая отражает точку зрения пользователей на данные в базе данных. Полученный скрипт может быть применен для создания физической базы данных. Создание физической модели базы данных: учет влияния транзакций - это этап, на котором анализируются возможные транзакции системы, выполняется, в случае необходимости, денормализация отношений для обеспечения более высокой производительности базы данных. На этом этапе создается скрипт создания физической базы данных. Создание серверного кода - это этап, на котором на основании функциональной модели предметной области базы данных создается серверный код базы данных в виде триггеров, хранимых процедур и пакетов. Эти модули создаются проектировщиком базы данных и выполняются сервером. Проектирование модулей приложений - это этап, на котором создаются спецификации модулей приложений, разрабатываются стратегии тестирования базы данных и приложений, создается план тестирования приложений базы данных и готовятся тестовые данные. Контроль качества проектирования базы данных заключается в проверке качества результатов проектирования на каждом его этапе. Учет задач обратного влияния заключается в настройке некоторых транзакций к базе данных и локальном перепроектировании базы данных согласно требованиям, поступающим с других этапов создания базы данных. Как правило, последние четыре из сформулированных нами задач решаются в соответствии с правилами и стандартами, принятыми в конкретной организации. Поэтому мы не будем строить для них детальной бизнес-модели в настоящей лекции, а в лекциях, посвященных рассмотрению этих задач, мы ограничимся понятийным материалом и установочными рекомендациями. В частности, задача контроля качества проектирования базы данных упомянута в настоящем курсе для полноты представления материала и как самостоятельная задача в настоящих лекциях не изучается. Это предмет отдельного курса лекций. |