ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 17.03.2024
Просмотров: 113
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Clipper (фирма Nantucket Inc.), FoxРro (фирма Fox Software), FoxВase+ (фирма Fox Software), Visual FoxРro (фирма Microsoft). Ранее достаточно большое время широко использовалась система управления базой данных РАRАDОХ произведенная фирмой Вorland International.
Уже в современности широкое распространение получила система управления базой данных Microsoft Аccess, которая является частью офисной программы Microsoft Оffice произведенной фирмой Microsoft и имеющей различный набор пакетов для различных пользователей.
Для крупных организаций имеющих катастрофическое количество данных и пользователей обстановка принципиально отличная от приведенной. Когда мы рассматривает такую ситуацию использование файл-серверных технологий является неудовлетворительным по приведенным ранее недостаткам данной архитектуры. Следовательно в данном случае уже используются промышленные или серверные системы управления базами данных.
Основными производителями таких систем обработки и хранения данных являются
3 корпорации: Oracle, Microsoft и IBM.
Наиболее распространенными клиент-серверными системами здесь соответственно являются системы Oracle (разработчик компания Oracle), Microsoft SQL Sеrver (разработчик компания Microsoft), DВ2, Informix Dynаmiс Servеr (компания IВМ).
Стадии проектирования базы данных
Проектирование любой информационной системы связано с жизненным циклом. База данных является частью информационной системы и программным продуктом. И как программный продукт база данных имеет собственный жизненный цикл БД (ЖЦБД). Жизненный цикл базы данных имеет множество составляющих, но главным является проектирование единого пространства (базы данных и программ) необходимого для ее работы. Поскольку база данных это центровой и наиболее фундаментальный компонент информационной системы то и жизненный цикл базы данных становится определяющим в понятии жизненного цикла всей информационной системы.
Рассмотрим этапы, которые включает в себя жизненный цикл базы данных:
План по которому будет разработана база данных (планирование);
Требования определяющие систему (определение);
Требования пользователей на основе сбора и анализа (анализ).
Что такое информационный объект? Информационный объект является сущностью в образе логически связанных реквизитов. Сущностью являются реальные объекты, явления, процессы и события. Сущностью для информационного объекта может быть: Университет, Факультет, Студент, сдача зачета и т.д. Логически связанные реквизиты это информационные элементы.
Класс или тип информационного объекта образуется путем выделения определенного реквизитного состава и структуры. Каждому классу (типу) присваивается уникальное имя или символьное обозначение, например, Факультет, Студент, Сессия.
Как реализуется информационный объект? Он имеет множество реализаций. Реализация информационного объекта это различные экземпляры. Каждый экземпляр определен как совокупность конкретных значений реквизитов и идентифицируется значением ключа. Ключ может простым и составным. Простой ключ определен одним реквизитом, составной ключ определен несколькими реквизитами. Те реквизиты, которые не определяют ключ, являются просто описательными. Надо учесть тот факт, что реквизиты определяющие ключ или ключевые (набор определенных реквизитов) информационного объекта для другого информационного объекта будут описательными. Каждый информационный объект может иметь как один, так и несколько ключей определяющих реквизиты.
Организуя различные наборы отношений информационных объектов и их взаимосвязи мы можем группировать одни и те же данные в таблицы или отношения. Группировка может происходить различными способами.
Минимизация дублирования данных и упрощение процедур обработки и обновления данных является главным аргументом при рациональном группировании атрибутов в отношениях.
Если сравнивать наборы отношений то получится, что какой-либо определенный набор отношений, отвечающий требованиям нормализации отношений при обработке и обновлении данных обладает лучшими свойствами.
Эдгаром Коддом были выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к совершенной третьей нормальной форме, который рассмотрим в следующих темах.
Концепции проектирования базы данных
Концепция проектирования базы данных состоит из цикла разработки и целей проектирования.
Рассмотрим что в себя включает цикл разработки. Цикл разработки базы данных включает в себя различные проектирования, такие как: концептуальное; логическое; физическое.
Теперь когда весь полный цикл проектирования базы данных определен необходимо определить цели проектирования как элемента концепции.
Целями проектирования базы данных являются:
Определенное представление данных и их взаимосвязей. Представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей.
2. Создание модели. Создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных.
3. Создание проекта. Разработка предварительного варианта проекта, структура которого позволяет удовлетворить требования, предъявляемые к производительности системы.
Концептуальное проектирование базы данных.
Создание концептуальной модели данных является первым этапом общего процесса проектирования базы данных. Построение первого этапа осуществляется с определенным порядком. В начале создания пользовательские представления данных представляются в виде подробных моделей. Далее эти модели комплексируются в полную концептуальную модель данных. Концептуальное проектирование неминуемо потребует создание концептуальной схемы базы данных.
Рассмотрим два основных существующих подхода к проектированию систем баз данных: с низу вверх или «восходящий»; с верху в низ или «нисходящий».
Первый подход применяется для проектирования простых баз данных с относительно небольшим количеством атрибутов. В этом случае проектирование начинается с самого нижнего уровня — уровня определения атрибутов. Атрибуты на основе анализа существующих между ними связей группируются в отношения. Полученные отношения в далее уже подвергаются процессу нормализации, который приводит к созданию нормализованных взаимосвязанных таблиц, основанных на функциональных зависимостях между атрибутами.
Второй подход связан с проектирование сложных баз данных с большим количеством атрибутов. Связано применение данного подхода с сложностью установки среди атрибутов всех существующих функциональных зависимостей. Свое начало данные подход берет с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей. Далее уже проектирование продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Наиболее ярким представителем данного подхода является концепция модели «сущность – связь» (Еntitу-Rеlatiоnshiр mоdеl – ЕR-модель) — самая популярная технология высокоуровневого моделирования данных, предложенная Питером Ченом.
Кроме этих двух основных подходов могут применяться и другие подходы, которые по сути являются комбинацией предложенных ранее подходов.
Рассмотрим этапы, выделенные при построении общей концептуальной модели:
1. Выделение локальных представлений, которые соответствуют относительно независимым данным. Каждое такое представление проектируется как подзадача.
2. Формулирование объектов, описывающих локальную предметную область проектируемой базы данных, и описание атрибутов, составляющих структуру каждого объекта.
3. Выделение ключевых атрибутов.
4. Спецификация связей между объектами. Удаление избыточных связей.
5. Анализ и добавление не ключевых атрибутов.
6. Объединение локальных представлений.
На основе анализа описания предметной области происходит построение концептуальной модели данных. Построение производится конечным пользователем на естественном языке. Тестированию и проверке на соответствие пользовательским требованиям концептуальная модель подвергается постоянно в процессе разработки. Концептуальная модель данных организации после своего создания является основой для следующей фазы – логического проектирования базы данных.
Логическое проектирование базы данных.
Целью второй или следующей фазы создания и проектирования базы данных является создание логической модели данных предметной области. Предметной областью можно считать исследуемую части организации или предприятия.
Отражением особенностей функционирования организации или предприятия в случае одновременного пользования многих пользователей занимается логическая модель, которая в этом случае называется глобальной логической моделью данных.Для ее создания выбирается один из двух подходов. Первый подход называется централизованным подходом. Второй подход называется на основе интеграции представлений.
Для централизованного подхода основным моментом является то, что он применяется только для очень сложных баз данных. Это связано с тем, что централизованный подход создается единый список требований, путем комплексирования всех требований пользователей.
Подход на основе интеграции представлений осуществляется при слиянии отдельных локальных логических моделей данных. Данные при этом отражают представления различных групп пользователей. Отельные локальные логические модели данных комплексируются в единую глобальную логическую модель данных всего предприятия или всей организации.
После этого создание или проектирование базы данных базируется на модель данных. К примеру модели данных могут быть реляционные, сетевые или иерархические. Такая модель данных может быть определена типом предполагаемой информационной системы управления базой данных необходимой для реализации. Именного после этого концептуальная модель может быть уточнена и преобразована в логическую модель данных.
Процесс разработки логической модели данных усложняется тем что в течении всего процесса модель должна постоянно проверяться на соответствие требований пользователей и на «неизбыточность», которая способна вызвать в будущем различные ошибки при обновлении и обработке.
Способность наглядно представить любые вносимые в базу данных изменения имеет созданная логическая модель, поэтому может использоваться как на этапе физического проектирования, так и на этапе эксплуатации и сопровождения даже уже готовой информационной системы.
На этапе логического проектирования готовятся следующие документы:
набор подсхем;
спецификация для физического проектирования приложений;
руководство по разработке программ (интерфейсов с пользователем и межпрограммных интерфейсов);
руководство по сопровождению базы данных.
Пока не будет получен программный продукт, соответствующий структуре предприятия или организации концептуальное и логическое проектирование рассматриваются во взаимосвязи и является интерактивным процессом, который включает в себя различные уточнения на протяжении всего взаимосвязанного этапа.
Уже в современности широкое распространение получила система управления базой данных Microsoft Аccess, которая является частью офисной программы Microsoft Оffice произведенной фирмой Microsoft и имеющей различный набор пакетов для различных пользователей.
Для крупных организаций имеющих катастрофическое количество данных и пользователей обстановка принципиально отличная от приведенной. Когда мы рассматривает такую ситуацию использование файл-серверных технологий является неудовлетворительным по приведенным ранее недостаткам данной архитектуры. Следовательно в данном случае уже используются промышленные или серверные системы управления базами данных.
Основными производителями таких систем обработки и хранения данных являются
3 корпорации: Oracle, Microsoft и IBM.
Наиболее распространенными клиент-серверными системами здесь соответственно являются системы Oracle (разработчик компания Oracle), Microsoft SQL Sеrver (разработчик компания Microsoft), DВ2, Informix Dynаmiс Servеr (компания IВМ).
Стадии проектирования базы данных
Проектирование любой информационной системы связано с жизненным циклом. База данных является частью информационной системы и программным продуктом. И как программный продукт база данных имеет собственный жизненный цикл БД (ЖЦБД). Жизненный цикл базы данных имеет множество составляющих, но главным является проектирование единого пространства (базы данных и программ) необходимого для ее работы. Поскольку база данных это центровой и наиболее фундаментальный компонент информационной системы то и жизненный цикл базы данных становится определяющим в понятии жизненного цикла всей информационной системы.
Рассмотрим этапы, которые включает в себя жизненный цикл базы данных:
План по которому будет разработана база данных (планирование);
Требования определяющие систему (определение);
Требования пользователей на основе сбора и анализа (анализ).
Что такое информационный объект? Информационный объект является сущностью в образе логически связанных реквизитов. Сущностью являются реальные объекты, явления, процессы и события. Сущностью для информационного объекта может быть: Университет, Факультет, Студент, сдача зачета и т.д. Логически связанные реквизиты это информационные элементы.
Класс или тип информационного объекта образуется путем выделения определенного реквизитного состава и структуры. Каждому классу (типу) присваивается уникальное имя или символьное обозначение, например, Факультет, Студент, Сессия.
Как реализуется информационный объект? Он имеет множество реализаций. Реализация информационного объекта это различные экземпляры. Каждый экземпляр определен как совокупность конкретных значений реквизитов и идентифицируется значением ключа. Ключ может простым и составным. Простой ключ определен одним реквизитом, составной ключ определен несколькими реквизитами. Те реквизиты, которые не определяют ключ, являются просто описательными. Надо учесть тот факт, что реквизиты определяющие ключ или ключевые (набор определенных реквизитов) информационного объекта для другого информационного объекта будут описательными. Каждый информационный объект может иметь как один, так и несколько ключей определяющих реквизиты.
Организуя различные наборы отношений информационных объектов и их взаимосвязи мы можем группировать одни и те же данные в таблицы или отношения. Группировка может происходить различными способами.
Минимизация дублирования данных и упрощение процедур обработки и обновления данных является главным аргументом при рациональном группировании атрибутов в отношениях.
Если сравнивать наборы отношений то получится, что какой-либо определенный набор отношений, отвечающий требованиям нормализации отношений при обработке и обновлении данных обладает лучшими свойствами.
Эдгаром Коддом были выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к совершенной третьей нормальной форме, который рассмотрим в следующих темах.
Концепции проектирования базы данных
Концепция проектирования базы данных состоит из цикла разработки и целей проектирования.
Рассмотрим что в себя включает цикл разработки. Цикл разработки базы данных включает в себя различные проектирования, такие как: концептуальное; логическое; физическое.
Теперь когда весь полный цикл проектирования базы данных определен необходимо определить цели проектирования как элемента концепции.
Целями проектирования базы данных являются:
Определенное представление данных и их взаимосвязей. Представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей.
2. Создание модели. Создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных.
3. Создание проекта. Разработка предварительного варианта проекта, структура которого позволяет удовлетворить требования, предъявляемые к производительности системы.
Концептуальное проектирование базы данных.
Создание концептуальной модели данных является первым этапом общего процесса проектирования базы данных. Построение первого этапа осуществляется с определенным порядком. В начале создания пользовательские представления данных представляются в виде подробных моделей. Далее эти модели комплексируются в полную концептуальную модель данных. Концептуальное проектирование неминуемо потребует создание концептуальной схемы базы данных.
Рассмотрим два основных существующих подхода к проектированию систем баз данных: с низу вверх или «восходящий»; с верху в низ или «нисходящий».
Первый подход применяется для проектирования простых баз данных с относительно небольшим количеством атрибутов. В этом случае проектирование начинается с самого нижнего уровня — уровня определения атрибутов. Атрибуты на основе анализа существующих между ними связей группируются в отношения. Полученные отношения в далее уже подвергаются процессу нормализации, который приводит к созданию нормализованных взаимосвязанных таблиц, основанных на функциональных зависимостях между атрибутами.
Второй подход связан с проектирование сложных баз данных с большим количеством атрибутов. Связано применение данного подхода с сложностью установки среди атрибутов всех существующих функциональных зависимостей. Свое начало данные подход берет с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей. Далее уже проектирование продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Наиболее ярким представителем данного подхода является концепция модели «сущность – связь» (Еntitу-Rеlatiоnshiр mоdеl – ЕR-модель) — самая популярная технология высокоуровневого моделирования данных, предложенная Питером Ченом.
Кроме этих двух основных подходов могут применяться и другие подходы, которые по сути являются комбинацией предложенных ранее подходов.
Рассмотрим этапы, выделенные при построении общей концептуальной модели:
1. Выделение локальных представлений, которые соответствуют относительно независимым данным. Каждое такое представление проектируется как подзадача.
2. Формулирование объектов, описывающих локальную предметную область проектируемой базы данных, и описание атрибутов, составляющих структуру каждого объекта.
3. Выделение ключевых атрибутов.
4. Спецификация связей между объектами. Удаление избыточных связей.
5. Анализ и добавление не ключевых атрибутов.
6. Объединение локальных представлений.
На основе анализа описания предметной области происходит построение концептуальной модели данных. Построение производится конечным пользователем на естественном языке. Тестированию и проверке на соответствие пользовательским требованиям концептуальная модель подвергается постоянно в процессе разработки. Концептуальная модель данных организации после своего создания является основой для следующей фазы – логического проектирования базы данных.
Логическое проектирование базы данных.
Целью второй или следующей фазы создания и проектирования базы данных является создание логической модели данных предметной области. Предметной областью можно считать исследуемую части организации или предприятия.
Отражением особенностей функционирования организации или предприятия в случае одновременного пользования многих пользователей занимается логическая модель, которая в этом случае называется глобальной логической моделью данных.Для ее создания выбирается один из двух подходов. Первый подход называется централизованным подходом. Второй подход называется на основе интеграции представлений.
Для централизованного подхода основным моментом является то, что он применяется только для очень сложных баз данных. Это связано с тем, что централизованный подход создается единый список требований, путем комплексирования всех требований пользователей.
Подход на основе интеграции представлений осуществляется при слиянии отдельных локальных логических моделей данных. Данные при этом отражают представления различных групп пользователей. Отельные локальные логические модели данных комплексируются в единую глобальную логическую модель данных всего предприятия или всей организации.
После этого создание или проектирование базы данных базируется на модель данных. К примеру модели данных могут быть реляционные, сетевые или иерархические. Такая модель данных может быть определена типом предполагаемой информационной системы управления базой данных необходимой для реализации. Именного после этого концептуальная модель может быть уточнена и преобразована в логическую модель данных.
Процесс разработки логической модели данных усложняется тем что в течении всего процесса модель должна постоянно проверяться на соответствие требований пользователей и на «неизбыточность», которая способна вызвать в будущем различные ошибки при обновлении и обработке.
Способность наглядно представить любые вносимые в базу данных изменения имеет созданная логическая модель, поэтому может использоваться как на этапе физического проектирования, так и на этапе эксплуатации и сопровождения даже уже готовой информационной системы.
На этапе логического проектирования готовятся следующие документы:
набор подсхем;
спецификация для физического проектирования приложений;
руководство по разработке программ (интерфейсов с пользователем и межпрограммных интерфейсов);
руководство по сопровождению базы данных.
Пока не будет получен программный продукт, соответствующий структуре предприятия или организации концептуальное и логическое проектирование рассматриваются во взаимосвязи и является интерактивным процессом, который включает в себя различные уточнения на протяжении всего взаимосвязанного этапа.