Файл: Тема концепция управления данными в современных информационных системах Цель лекции.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.11.2023
Просмотров: 241
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
, можно разделить на две группы. Первую группу составляют операции над множествами, к которым относятся операции: объединения, пересечения, разности, деления и декартова произведения. Вторую группу составляют специальные операции над отношениями, к которым, в частности, относятся операции: проекции, соединения, выбора.
В различных СУБД реализована некоторая часть операций над отношениями, определяющая в какой-то мере возможности данной СУБД и сложность реализации запросов к БД.
В реляционных СУБД для выполнения операций над отношениями используются две группы языков, имеющие в качестве своей математической основы теоретические языки запросов, предложенные Э.Коддом:
реляционная алгебра;
реляционное исчисление.
Эти языки представляют минимальные возможности реальных языков манипулирования данными в соответствии с реляционной моделью и эквивалентны друг другу по своим выразительным возможностям. Существуют правила преобразования запросов между ними.
В реляционной алгебре операнды и результаты всех действий являются отношениями. Языки реляционной алгебры являются процедурными, так как отношение, являющееся результатом запроса к реляционной БД, вычисляется при выполнении последовательности реляционных операторов, применяемым к отношениям. Операторы состоят из операндов, в роли которых выступают отношения, и реляционных операций. Результатом реляционной операции является отношение.
Языки исчислений, в отличие от реляционной алгебры, являются непроцедурными. (описательными, или декларативными) и позволяют выражать запросы с помощью предиката первого порядка (высказывания в виде функции), которому должны удовлетворять кортежи или домены отношений. Запрос к БД, выполненный с использованием подобного языка, содержит лишь информацию о желаемом результате. Для этих языков характерно наличие наборов правил для записи запросов. В частности, к языкам этой группы относится SQL
ТЕМА 5. Проектирование базы данных
Цель лекции: изучить этапы проектирования баз данных.
Ключевые слова: жизненный цикл, стадии, инфологическое проектирование, модель, сущность, связь, атрибут, логическое проектирование, отношение, нормализация, физическая модель, схема хранения, CASE-средства, моделирование, репозитарий.
План лекции
1.Процесс проектирования, реализации и поддержания системы базы данных называется жизненным циклом базы данных (ЖЦБД).Процедура создания системы называется жизненным циклом системы (ЖЦС).
Понимание и правильный подход к ЖЦБД очень важен и требует детального рассмотрения, так как в его основе лежит подход, ориентированный на данные. Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа классов единиц данных и отношений между ними. Если построить логичную схему базы данных, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Функционально-ориентированный подход можно применять лишь для создания временных систем, которые рассчитаны на недолгое время функционирования.
Стадии жизненного цикла базы данных:
- Стадия анализа – производится анализ предметной области и выявляются требования к ней. Происходит оценка актуальности разработки.
- Стадия проектирования – создается логическая структура базы данных, функциональное описание программных модулей и информационных запросов. БД подготавливается к эксплуатации.
- Стадия реализации – решаются задачи по разработке программного доступа к базе данных. Проводится тестирование.
- Стадия эксплуатации и сопровождения.
Жизненный цикл базы данных состоит из следующих этапов:
1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:
Данная информация помогает определить, как используется информация приложений, определить будущие требования к системе БД.
Информация этого этапа документируется в виде обобщенной модели данных.
2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:
3. Определение требованийвключает выбор целей БД, выяснение информационных требований к системе и требований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель, выражающаяся в следующих задачах:
4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.
Основным выходным документом является единая инфологическая модель
(или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.
5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.
1) Выбор и приобретение необходимой СУБД.
2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:
3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.
4) Заполнение базы данных.
5) Создание прикладных программ, контроль управления.
6) Обучение пользователей.
6. Оценка и усовершенствование схемы БД.Включает опрос пользователей с целью выяснения функциональных неучтенных потребностей. При необходимости вносятся изменения, добавление новых программ и элементов данных по мере изменения и расширения потребностей.
Таким образом, ЖЦБД включает в себя:
2.Цель инфологического этапа проектирования состоит в получении семантических (концептуальных) моделей, отражающих предметную область и информационные потребности пользователей. В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования является неформальная модель "Сущность-Связь" (ER-модель - Entity-Relationship). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов.
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность (объект) - это реальный или представляемый объект предметной области, информация о котором должна сохраняться и быть доступна. Различают такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов, событий, личностей, выступающих как единое целое. Экземпляр сущности относится к конкретной вещи в наборе. В диаграммах ER-модели сущность представляется в виде прямоугольника (в нотации Баркера), содержащего имя сущности.
Атрибут - поименованная характеристика сущности, определяющая его свойства и принимающая значения из некоторого множества значений. Каждый атрибут обеспечивается именем, уникальным в пределах сущности.
Атрибуты могут классифицироваться по принадлежности к одному из трех различных типов: описательные, указывающие, вспомогательные. Описательные атрибуты представляют факты, внутренне присущие каждому экземпляру сущности. Указывающие атрибуты используются для присвоения имени или обозначения экземплярам сущности. Вспомогательные атрибуты используются для связи экземпляра одной сущности с экземпляром другого. Атрибуты подчиняются строго определенным правилам.
Множество из одного или нескольких атрибутов, значения которых однозначно определяют каждый экземпляр сущности, называются идентификатором. Каждый экземпляр сущности должен иметь хотя бы один идентификатор. Если идентификаторов несколько, один из них выбирается как привилегированный.
Связь (Relationship) - это поименованная графически изображаемая ассоциация, устанавливаемая между сущностями и представляющая собой абстракцию набора отношений, которые систематически возникают между различными видами предметов в реальном мире. Большинство связей относятся к категории бинарных и имеют место между двумя сущностями.
В различных СУБД реализована некоторая часть операций над отношениями, определяющая в какой-то мере возможности данной СУБД и сложность реализации запросов к БД.
В реляционных СУБД для выполнения операций над отношениями используются две группы языков, имеющие в качестве своей математической основы теоретические языки запросов, предложенные Э.Коддом:
реляционная алгебра;
реляционное исчисление.
Эти языки представляют минимальные возможности реальных языков манипулирования данными в соответствии с реляционной моделью и эквивалентны друг другу по своим выразительным возможностям. Существуют правила преобразования запросов между ними.
В реляционной алгебре операнды и результаты всех действий являются отношениями. Языки реляционной алгебры являются процедурными, так как отношение, являющееся результатом запроса к реляционной БД, вычисляется при выполнении последовательности реляционных операторов, применяемым к отношениям. Операторы состоят из операндов, в роли которых выступают отношения, и реляционных операций. Результатом реляционной операции является отношение.
Языки исчислений, в отличие от реляционной алгебры, являются непроцедурными. (описательными, или декларативными) и позволяют выражать запросы с помощью предиката первого порядка (высказывания в виде функции), которому должны удовлетворять кортежи или домены отношений. Запрос к БД, выполненный с использованием подобного языка, содержит лишь информацию о желаемом результате. Для этих языков характерно наличие наборов правил для записи запросов. В частности, к языкам этой группы относится SQL
ТЕМА 5. Проектирование базы данных
Цель лекции: изучить этапы проектирования баз данных.
Ключевые слова: жизненный цикл, стадии, инфологическое проектирование, модель, сущность, связь, атрибут, логическое проектирование, отношение, нормализация, физическая модель, схема хранения, CASE-средства, моделирование, репозитарий.
План лекции
-
Жизненный цикл базы данных -
Инфологическое и логическое проектирование базы данных -
Физическое проектирование БД -
Программные средства проектирования БД
1.Процесс проектирования, реализации и поддержания системы базы данных называется жизненным циклом базы данных (ЖЦБД).Процедура создания системы называется жизненным циклом системы (ЖЦС).
Понимание и правильный подход к ЖЦБД очень важен и требует детального рассмотрения, так как в его основе лежит подход, ориентированный на данные. Элементы данных более стабильны, чем выполняемые функции системы. Создание правильной структуры данных требует сложного анализа классов единиц данных и отношений между ними. Если построить логичную схему базы данных, то в дальнейшем можно создать любое количество функциональных систем, использующих эту схему. Функционально-ориентированный подход можно применять лишь для создания временных систем, которые рассчитаны на недолгое время функционирования.
Стадии жизненного цикла базы данных:
- Стадия анализа – производится анализ предметной области и выявляются требования к ней. Происходит оценка актуальности разработки.
- Стадия проектирования – создается логическая структура базы данных, функциональное описание программных модулей и информационных запросов. БД подготавливается к эксплуатации.
- Стадия реализации – решаются задачи по разработке программного доступа к базе данных. Проводится тестирование.
- Стадия эксплуатации и сопровождения.
Жизненный цикл базы данных состоит из следующих этапов:
1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:
-
какие прикладные программы используются, и какие функции они выполняют; -
какие файлы связаны с каждым из этих приложений; -
какие новые приложения и файлы находятся в процессе работы.
Данная информация помогает определить, как используется информация приложений, определить будущие требования к системе БД.
Информация этого этапа документируется в виде обобщенной модели данных.
2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:
-
технологическая осуществимость – есть ли технология для реализации запланированной БД? -
операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД? -
экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?
3. Определение требованийвключает выбор целей БД, выяснение информационных требований к системе и требований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель, выражающаяся в следующих задачах:
-
Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы. -
Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов. -
Определение общих требований к оборудованию и программному обеспечению, связанных с поддержанием желаемого уровня быстродействия. (Выяснение количества пользователей системы, числа входных сообщений в день, количество распечаток). Данная информация используется для выбора типов компьютеров и СУБД, объёма дисков, количества принтеров. Данные этого этапа излагаются в отчёте, содержащем примерные конфигурации оборудования и программного обеспечения. -
Разработка плана поэтапного создания системы, включающий выбор исходных приложений.
4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.
Основным выходным документом является единая инфологическая модель
(или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.
5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.
1) Выбор и приобретение необходимой СУБД.
2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:
-
на основе инфологической модели данных строится схема данных для конкретной СУБД, при необходимости реализуется денормализация БД с целью ускорения обработки запросов во всех критичных по времени приложениях; -
определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры; -
реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных; -
спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения; -
разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов; -
определить уровни доступа пользователей, разработать и внедрить правила обеспечения безопасности и аудита. Создать роли и синонимы для обеспечения многопользовательского доступа с согласованными уровнями полномочий доступа. -
разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).
3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.
4) Заполнение базы данных.
5) Создание прикладных программ, контроль управления.
6) Обучение пользователей.
6. Оценка и усовершенствование схемы БД.Включает опрос пользователей с целью выяснения функциональных неучтенных потребностей. При необходимости вносятся изменения, добавление новых программ и элементов данных по мере изменения и расширения потребностей.
Таким образом, ЖЦБД включает в себя:
-
Изучение предметной области и представление соответствующей документации (1-3). -
Построение инфологической модели (4). -
Реализация (5). -
Оценка работы и поддержка БД (6).
2.Цель инфологического этапа проектирования состоит в получении семантических (концептуальных) моделей, отражающих предметную область и информационные потребности пользователей. В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования является неформальная модель "Сущность-Связь" (ER-модель - Entity-Relationship). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов.
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность (объект) - это реальный или представляемый объект предметной области, информация о котором должна сохраняться и быть доступна. Различают такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов, событий, личностей, выступающих как единое целое. Экземпляр сущности относится к конкретной вещи в наборе. В диаграммах ER-модели сущность представляется в виде прямоугольника (в нотации Баркера), содержащего имя сущности.
Атрибут - поименованная характеристика сущности, определяющая его свойства и принимающая значения из некоторого множества значений. Каждый атрибут обеспечивается именем, уникальным в пределах сущности.
Атрибуты могут классифицироваться по принадлежности к одному из трех различных типов: описательные, указывающие, вспомогательные. Описательные атрибуты представляют факты, внутренне присущие каждому экземпляру сущности. Указывающие атрибуты используются для присвоения имени или обозначения экземплярам сущности. Вспомогательные атрибуты используются для связи экземпляра одной сущности с экземпляром другого. Атрибуты подчиняются строго определенным правилам.
Множество из одного или нескольких атрибутов, значения которых однозначно определяют каждый экземпляр сущности, называются идентификатором. Каждый экземпляр сущности должен иметь хотя бы один идентификатор. Если идентификаторов несколько, один из них выбирается как привилегированный.
Связь (Relationship) - это поименованная графически изображаемая ассоциация, устанавливаемая между сущностями и представляющая собой абстракцию набора отношений, которые систематически возникают между различными видами предметов в реальном мире. Большинство связей относятся к категории бинарных и имеют место между двумя сущностями.