Новые книги
 Где должен быть прогрессивный маркетолог? Там, где находятся клиенты его компании. А куда многие из них нынче бросаются, едва проснувшись утром? Где проводят часы напролет, где берут информацию, которой доверяют? В Интернете, а точнее – в социальных сетях. Крупнейшая на сегодняшний день – сеть Facebook – из скромного университетского портала стремительно превратилась в грандиозное хранилище данных и гибкий инструмент общения, нетворкинга и самого эффективного сейчас маркетинга – маркетинга в социальных сетях.Книга откроет новые возможности владельцам и руководителям компаний от мала до велика, а также маркетологам всех рангов. |
 «Дорого!», «У нас есть поставщик!», «Отправьте предложение на e-mail», «Нам не надо!», «Я подумаю…» – клиент может сказать свое «НЕТ» продавцу десятками способов. Успешного продавца отличает умение выстроить диалог так, чтобы возражения вообще не возникли, и знание готовых ответов на все основные возражения, отговорки и отказы. Если, осуществляя холодные звонки или продавая на встречах, вы сталкиваетесь с возражениями и отказами – эта книга для вас! Она даст вам 200+ приемов и готовых речевых модулей, благодаря которым вы будете легко преодолевать «нет» и выведете ваши навыки продаж и уровень доходов на новый уровень.Все приемы протестированы в скриптах продаж и показали высокую эффективность в российских условиях. |
Архитектура СУБД
1.3. Архитектура СУБД
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, которые практически не имеют и (или) не хотят иметь представления о:
- физическом размещении в памяти данных и их описаний;
- механизмах поиска запрашиваемых данных;
- проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
- способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
- поддержании баз данных в актуальном состоянии
и множестве других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?
Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (рис. 1.3).
Рис. 1.3. Уровни моделей данных
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Остальные модели, показанные на рис. 1.3, являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся "прозрачными" для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
[Назад] [Содержание] [Вперед]