Классификационные группировки, относящиеся к БнД в целом
⇐ ПредыдущаяСтр 4 из 4 Следующая группа признаков классификации связана с банком данных в целом. По условиям предоставления услуг различают бесплатные и платные банки данных. Платные БД в свою очередь делятся на бесприбыльные и коммерческие. Бесприбыльные банки данных функционируют на принципе самоокупаемости и не ставят своей целью получение прибыли. Это обычно БнД социально значимой информации, имеющей широкий круг пользователей, или научной, библиотечной информации. Основной целью создания коммерческих банков данных является получение прибыли от информационной деятельности. Информационные системы различаются по характеру преобладающей обработки информации. В одних в основном реализуется большое число достаточно простых запросов (такие системы получили название OLTP (On-Line Transaction Processing) — системы оперативной обработки транзакций). В других, напротив, требуется сложная аналитическая обработка данных (для такого класса систем стал использоваться термин OLAP (On-line Analytical Processing)). Термин OLAP является сравнительно новым и в разных литературных источниках трактуется иногда по-разному. Этот термин часто отождествляют с поддержкой принятия решений (DSS (Decision Support Systems) — системы поддержки принятия решения). А в качестве синонима для последнего термина используют Data Warehousing — хранилища (склады) данных, понимая под этим набор организационных решений, программных и аппаратных средств для обеспечения аналитиков информацией на основе данных из систем обработки транзакций нижнего уровня и других источников. «Склады данных» позволяют обрабатывать данные, накопленные за длительные периоды времени. Эти данные являются разнородными (и не обязательно структурированными). Для «складов данных» присущ многомерный характер запросов. Огромные объемы данных, сложность структуры как данных, так и запросов требует использования специальных методов доступа к информации.
В других источниках понятие Системы Поддержки Принятия Решений (СППР) считается более широким. Хранилища данных и средства оперативной аналитической обработки могут служить одними из компонентов архитектуры СППР. Иногда различают "OLAP в узком смысле" — это системы, которые обеспечивают только выборку данных в различных разрезах, и "OLAP в широком смысле", или просто OLAP, включающей в себя: · поддержку нескольких пользователей, редактирующих БД; · функции моделирования, в том числе вычислительные механизмы получения производных результатов, а также агрегирования и объединения данных; · прогнозирование, выявление тенденций и статистический анализ. Естественно, что каждый из этих типов ИС требует специфической организации данных, а так же специальных программных средств, обеспечивающих эффективное выполнение стоящих задач. Для обеспечения быстрой обработки данных при их анализе используются разнообразные приемы. Одним из них является организация данных в виде так называемых многомерных БД (MDD). Информация в MDD хранится не в виде индексированных записей в таблицах, а в форме логически упорядоченных массивов. Единой общепризнанной многомерной модели хранения данных не существует. В MDD отсутствует стандартизованный метод доступа к данным, и они могут отвечать требованиям специфической аналитической обработки данных.
Хранилища данных могут быть разбиты на два типа: корпоративные хранилища данных (enterprise data warehouses) и киоски данных (data marts).
Корпоративные хранилища данных содержат информацию, относящуюся ко всей корпорации и собранную из множества оперативных источников для консолидированного анализа. Обычно такие хранилища охватывают целый ряд аспектов деятельности корпорации и используются для принятия как тактических, так и стратегических решений. Киоски данных содержат подмножество корпоративных данных и строятся для отделов или подразделений внутри организации. Киоски данных часто строятся силами самого отдела и охватывают конкретный аспект, интересующий сотрудников данного отдела. Киоск данных может получать данные из корпоративного хранилища (зависимый киоск), или, что более распространено, данные могут поступать непосредственно из оперативных источников (независимый киоск). Киоски и хранилища данных строятся по сходным принципам и используют практически одни и те же технологии. По степени доступности БнД делятся на общедоступные и с ограниченным кругом пользователей. По охвату БД могут классифицироваться в свою очередь в разных «разрезах»: · территориальный o всемирный o... o страна o... o город o... · временной · ведомственный · проблемный (тематический) Территориальный и ведомственный признаки классификации могут относиться не только к информации, хранящейся БД, но и к кругу обслуживаемых пользователей. По характеру взаимодействия с пользователями (кто инициализирует действия) БнД делятся на: · активные БнД · пассивные БнД. В пассивных БнД ведущая роль принадлежит пользователю. В активных – система может самостоятельно менять поведение. В последнее время термин «активная база данных» стал часто использоваться для систем, использующих тригерры. По форме собственности БнД делятся на: · государственные · негосударственные · частные · групповые · личные. В литературе встречаются и другие аспекты классификации банков данных, но названные являются наиболее значимыми.
Уровни моделей и этапы проектирования БД Уровни моделей В базе данных отражается информация об определенной предметной области. Предметной областью называется часть реального мира, представляющая интерес для данного исследования. В автоматизированных информационных системах отражение предметной области обеспечивается посредством информационной модели. Мы будем рассматривать далее вопросы проектирования баз данных для СУБД, поддерживающих структурированные модели данных. В зависимости от аспекта рассмотрения (уровня абстракции) различают модели данных нескольких уровней. Число реально выделенных и самостоятельно поддерживаемых уровней моделей будет зависеть от особенностей СУБД. Чаще всего выделяют три уровня моделей: логический, физический и внешний. Даталогическая (datalogical) модель (ДЛМ) базы данных является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к среде хранения. Эта модель строится в терминах информационных единиц, допустимых в той конкретной СУБД, в среде которой мы проектируем базу данных. Этап создания ДЛМ называется даталогическим проектированием. Описание логической структуры базы данных на языке СУБД называется схемой. Для привязки даталогической модели к среде хранения используется модель данных физического уровня (для краткости часто называемая физической моделью). Эта модель определяет используемые запоминающие устройства, способы физической организации данных в среде хранения. Модель физического уровня также строится с учетом возможностей, предоставляемых СУБД. Описание физической структуры базы данных называется схемой хранения. Соответствующий этап проектирования БД называется физическим проектированием. СУБД обладают разными возможностями по физической организации данных, в связи с чем сложность и трудоемкость физического проектирования, набор выполняемых шагов различаются для конкретных систем. К числу работ, выполняемых на этапе физического проектирования, относятся: выбор типа носителя, способа организации данных, методов доступа, определение размера физического блока, управление размещением данных на внешнем носителе, управление свободной памятью, определение целесообразности сжатия данных и используемых методов сжатия, оценка физической модели данных. К физическому проектированию относятся и проблемы, связанные с буферизацией
Независимо от того, поддерживаются в явном виде отдельно модели логического и физического уровня, с точки зрения методологии все равно можно выделить эти уровни моделей и соответствующие им этапы проектирования баз данных. В некоторых СУБД, помимо описания общей логической структуры базы данных, имеется возможность описать логическую структуру БД с точки зрения конкретного пользователя. Такая модель называется внешней, а ее описание называется подсхемой. Если СУБД "поддерживает" схему, схему хранения и подсхему, то она является СУБД с трехуровневой архитектурой. Внешняя модель не всегда является точным подмножеством схемы. Некоторые СУБД допускают различия в типах данных, определенных в схеме и подсхеме, и обеспечивают их преобразование, позволяют задавать различный логический порядок следования элементов в схеме и подсхеме, обеспечивают введение в подсхему виртуальных полей и т. д.. Если определена подсхема, то пользователь имеет доступ только к тем данным, которые отражены в соответствующей подсхеме, что является одним из способов защиты информации от несанкционированного доступа. В подсхемах часто задается не только логическая структура части базы данных с точки зрения конкретного пользователя (приложения), но и допустимые режимы обработки в рамках этой подсхемы, что служит дополнительным механизмом защиты информации от разрушения. Использование аппарата подсхем облегчает работу пользователя, так как он должен знать структуру не всей базы данных, а только той ее части, которая имеет непосредственное отношение к нему. В тех случаях, когда СУБД в явном виде не поддерживает подсхемы, перечисленные функции могут выполнять другие компоненты системы. Близким к понятию подсхемы является понятие view (взгляд), которое в настоящее время широко используется в англоязычной литературе по реляционным СУБД. Выше мы говорили о трех уровнях моделей, которые поддерживаются СУБД. Но для того, чтобы спроектировать структуру базы данных, необходима исходная информация о предметной области. Желательно, чтобы эта информация была представлена в формализованном виде. Такое формализованное описание предметной области будем называть инфологической (infological) моделью предметной области (ИЛМ)[1]или концептуальной моделью (КМ). Информация, требуемая для проектирования БД, мало зависит от особенностей СУБД. Более того, для проектирования ИС с "небанковской" организацией (но использующей структурированное представление данных) обычно требуется та же исходная информация. Поэтому концептуальная схема представляет собой описание предметной области, выполненное без жесткой ориентации на используемые в дальнейшем программные и технические средства. Концептуальная схема должна отражать специфику предметной области, а не структуру БД. Иногда в концептуальную схему добавляют информацию, отображающую чисто языковые характеристики, такие как наличие синонимов, длина реквизитов и др. Это, скорее всего, вызвано следующими основными причинами:
1. нежеланием вводить еще один уровень моделей, 2. трудностью отделения языковых проблем от других, так как анализируемая предметная область обычно представлена в какой-либо знаковой системе, и анализу обычно подвергается именно это представление, а не непосредственно сама ПО.
Воспользуйтесь поиском по сайту: ©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...
|