Главная страница
Навигация по странице:

  • Типы данных.

  • Разделение систем управления базами данных на настольные и промышленные

  • Концепции проектирования базы данных

  • Концептуальное проектирование базы данных.

  • Логическое проектирование базы данных.

  • Лекции по Базам данных. лекции. Развитие технологий обработки данных


    Скачать 0.53 Mb.
    НазваниеРазвитие технологий обработки данных
    АнкорЛекции по Базам данных
    Дата16.02.2023
    Размер0.53 Mb.
    Формат файлаdocx
    Имя файлалекции.docx
    ТипДокументы
    #940385
    страница12 из 22
    1   ...   8   9   10   11   12   13   14   15   ...   22

    Объектно-ориентированная модель.

    В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.

    Стандартизованная объектно-ориентированной модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group — группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается.

    Структура объектно-ориентированной базы данных графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым — string) или типом, конструируемым пользователем (определяется как class).

    Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в базе данных образуют связную иерархию объектов.

    Внешне логическая структура объектно-ориентированной базы данных внешне схожа с структурой иерархической базы данных. Но есть отличия, основным из которых являются методы манипулирования данных.

    Рассматриваемая модель базы данных может выполнять какие-либо действия над данными применяя логические операции, которые усилены объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма. С некоторыми ограничениями, но все таки могут применяться операции, подобные командам SQL.

    Проектирование, создание и изменение базы данных в данной модели может сопровождаться автоматическим формированием и последующей корректировкой индексов или так называемых индексных таблиц. Индексы или индексные таблицы содержат информацию для быстрого поиска данных.

    К чему сводится поиск объектов в объектно-ориентированной базе данных? Он заключается в выборе конкретных элементов сходства между теми элементами или объектами, которые задает системе пользователь и элементами или объектами, которые хранятся в базе данных. Пользователь определяет объект. Определение объекта значит задаются свойства объекта (gоаt) и называется объектом-целью. Объект-цель может представлять подмножество всей хранимой в базе данных иерархии объектов. Так же как и результаты выполненных запросов, объект-цель может храниться в самой базе данных.

    Объектно-ориентированные модели данных обладают достоинством, которое по сравнению с реляционной моделью является важным и говорит о возможности отображать информацию не простых взаимосвязях объектов базы данных. Они так же позволяют пользователю идентифицировать отдельную запись базы данных и определять функции их обработки.

    К недостаткам объектно-ориентированной модели можно отнести высокую понятийную сложность, неудобство обработки данных и низкую скорость выполнения запросов.

    Типы данных.

    На первом и последующих этапах своего развития системы управления базами данных преимущественно использовались для решения финансово-экономических задач. Надо отметить, что основные типы данных используются независимо от моделей представления. В базах данных используются в основном следующие типы данных:

          числовые. Примеры значений данных: 0,43; 328; 326,456; 2Е+4;

          символьные или алфавитно-цифровые. Примеры значений данных: «суббота», «столбец», «начальник»;

          даты, задаваемые с помощью специального типа «Дата» или как обычные символьные данные. Примеры значений данных: 2.06.14, 14/6/2015.

    В отличии от приведенных типов, необходимо отметить, что различие систем управления базами данных не обуславливается существенным различием этих типов. Они могут незначительно отличаться друг от друга по различным критериям (название, диапазон значений, вид представления). В современных условиях, когда стала необходимость в появлении различных специализированных систем (обработка видео, геоинформационные системы) стали появляться новые типы данных. Они стали добавляться к традиционным в классические системы управления базами данных. К их числу можно отнести следующие новые типы данных:

    временные и дата-временные, предназначенные для хранения информации о времени и/или дате. Примеры значений данных: 31.01.15 (дата), 9:10:03 (время), 20.05.1969 02:00 (дата и время);

    символьные переменной длины, предназначенные для хранения текстовой информации большой длины, например, текстовый документ в различных текстовых форматах;

    двоичные, предназначенные для хранения графических объектов, аудио- и видеоинформации, пространственной, хронологической и другой специальной информации. Например, в Мicrosoft Aссess таким типом является тип данных «Поле объекта ОLЕ», который позволяет хранить в БД графические данные в формате ВМР (Вitmap) и отображать их в автоматическом режиме при работе с базой данных;

    гиперссылки (hyperlinks), предназначенные для хранения ссылок на различные ресурсы (узлы, файлы, документы и т.д.), находящиеся вне базы данных, например, в сети Internet, корпоративной сети intranet или на жестком диске компьютера или сервера.

    В современных системах управления базой данных с различными моделями данных могут использоваться все перечисленные типы данных.

     

    Разделение систем управления базами данных на настольные и промышленные

    Когда необходимо выполнить сравнительно небольшие задачи используются настольные системы управления базами данных. Сравнительно небольшие задачи подразумевают, использование небольшого объема обрабатываемой информации и, сравнительно малого количества пользователей). Настольные системы управления базами данных имеют упрощенную архитектуру , то есть могут функционировать в файл-серверном режиме. Такие системы поддерживают на все возможные функции системы управления базой данных. Может не вестись журнал транзакций, может отсутствовать возможность автоматического восстановления базы данных после сбоев и многое другое. Несмотря на приведенные существенные ограничения эти системы имеют обширную применяемую область. Это могут быть государственные и муниципальные учреждения, организации сфера образования, предприятия сфера обслуживания а так же различные фирмы малого и среднего бизнеса. Возникающие задачи в приведенной области применения имеют специфика, которая заключается в не огромных объемах данных, в низкой частоте обновления, в территориальной близости и небольшом количестве пользователей. В приведенных условиях использование настольных систем управления базами данных с их существенными ограничениями является рентабельным.

    Первыми системами управления базами данных были так называемые dВase-совместимые программные системы, разработанные параллельно совершенно разными фирмами. Система dВase III – РLUS произведенная фирмой Аchton-Тate стала первой системой такого класса, получившей достаточно широкое распространение. Развитые языковые возможности, с точки зрения программирования, очень удобный или «дружественный» интерфейс, доступный для любого даже очень массового пользователя, стали основными причинами широчайшего распространения данной системы. Тем не менее, есть сложности обусловленные низкой производительностью на стадии интерпретации, что неизбежно повлияло на появление новых систем-компиляторов, близких к системе dВase III – РLUS: 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. Объединение локальных представлений.

    На основе анализа описания предметной области происходит построение концептуальной модели данных. Построение производится конечным пользователем на естественном языке. Тестированию и проверке на соответствие пользовательским требованиям концептуальная модель подвергается постоянно в процессе разработки. Концептуальная модель данных организации после своего создания является основой для следующей фазы – логического проектирования базы данных.

    Логическое проектирование базы данных.

    Целью второй или следующей фазы создания и проектирования базы данных является создание логической модели данных предметной области. Предметной областью можно считать исследуемую части организации или предприятия.

    Отражением особенностей функционирования организации или предприятия в случае одновременного пользования многих пользователей занимается логическая модель, которая в этом случае называется глобальной логической моделью данных.Для ее создания выбирается один из двух подходов. Первый подход называется централизованным подходом. Второй подход называется на основе интеграции представлений.

    Для централизованного подхода основным моментом является то, что он применяется только для очень сложных баз данных. Это связано с тем, что централизованный подход создается единый список требований, путем комплексирования всех требований пользователей.

    Подход на основе интеграции представлений осуществляется при слиянии отдельных локальных логических моделей данных. Данные при этом отражают представления различных групп пользователей. Отельные локальные логические модели данных комплексируются в единую глобальную логическую модель данных всего предприятия или всей организации.

    После этого создание или проектирование базы данных базируется на модель данных. К примеру модели данных могут быть реляционные, сетевые или иерархические. Такая модель данных может быть определена типом предполагаемой информационной системы управления базой данных необходимой для реализации. Именного после этого концептуальная модель может быть уточнена и преобразована в логическую модель данных.

    Процесс разработки логической модели данных усложняется тем что в течении всего процесса модель должна постоянно проверяться на соответствие требований пользователей и на «неизбыточность», которая способна вызвать в будущем различные ошибки при обновлении и обработке.

    Способность наглядно представить любые вносимые в базу данных изменения имеет созданная логическая модель, поэтому может использоваться как на этапе физического проектирования, так и на этапе эксплуатации и сопровождения даже уже готовой информационной системы.

    На этапе логического проектирования готовятся следующие документы:

          набор подсхем;

          спецификация для физического проектирования приложений;

          руководство по разработке программ (интерфейсов с пользователем и межпрограммных интерфейсов);

          руководство по сопровождению базы данных.

    Пока не будет получен программный продукт, соответствующий структуре предприятия или организации концептуальное и логическое проектирование рассматриваются во взаимосвязи и является интерактивным процессом, который включает в себя различные уточнения на протяжении всего взаимосвязанного этапа.
    1   ...   8   9   10   11   12   13   14   15   ...   22


    написать администратору сайта