Шпаргалки по БД (базам данных) и СУБД (системам управления базами данных).
1) Файловые системы. Недостатки. С точки зрения пп файл - это именованная об-ласть внешней памяти, в которую можно записывать и из которой можно считывать данные. Правила именования файлов, способ доступа к данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления файлами и, возможно, от типа файла. Система управления файлами берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса во внешней памяти и обеспечение доступа к данным. Недостатки ■ Разделение и изоляция данных. ■ Дублирование данных. ■ Зависимость от данных. ■ Несовместимость файлов. ■ Фиксированные запросы/быстрое увеличение количества приложений. Разделение и изоляция данных Когда данные изолированы в отдельных файлах, доступ к ним весьма затруднен. На-пример, для создания списка всех домов, отвечающих требованиям потенциаль¬ных арендаторов, предварительно нужно создать временный файл со списком арен¬даторов, желающих арендовать недвижимость типа "дом". Затем в файле следует осуществить поиск объектов недвижимости типа "дом" с арендной платой ниже установленного арендатором максимума. Выполнять подобную обработку данных в файловых системах достаточно сложно. Для извлечения соответ¬ствующей поставленным условиям информации программист должен организовать синхронную обработку двух файлов. Трудности существенно возрастают, когда необ¬ходимо извлечь данные из более чем двух файлов. Дублирование данных Из-за децентрализованной работы с данными, проводимой в каждом отделе неза¬висимо от других отделов, в файловой системе фактически поощряется бесконтроль¬ное дублирование данных, и это, в принципе, неизбежно. Бесконтрольное дублирование данных неже¬лательно по следующим двум причинам. 1. Дублирование данных сопровождается неэкономным расходованием ресурсов, по¬скольку на ввод избыточных данных требуется затрачивать дополнительные вре¬мя и деньги. Во многих случаях дублирования данных можно избежать за счет совместного ис¬пользования файлов. 2. Еще более важен тот факт, что дубли-рование данных может привести к нару¬шению их целостности. Иначе говоря, данные в разных отделах могут стать противоречивыми. Например, рассмотрим случай дублирова¬ния данных в бухгалтерии и отделе кадров. Если сотрудник переедет в другой дом и изменение адреса будет зафиксировано только в отделе кадров, то уведом-ление о зарплате будет послано ему по старому адресу. При обнаружении подобной ошибки для ее исправления потребуется затратить до¬полнительное время и средства. Поскольку не суще¬ствует никакого автоматического способа обновления данных одновременно и в файлах отдела кадров, и в файлах расчетного сектора, нетрудно предвидеть, что подобные противоречия время от времени обязательно будут возникать. Зависимость от данных Как уже упоминалось выше, физическая струк-тура и способ хранения записей файлов данных жестко зафиксированы в коде программ приложений. Это значит, что изменить существующую структуру данных достаточно сложно. Например, увеличение в файле длины поля адреса с 40 до 41 символа ка¬жется совершенно незначительным изменением его структуры, но для воплощения этого изменения потребуется, как минимум, создать одноразовую программу спе-циального назначения (т.е. программу, которая выполняется только один раз), преобразующую уже существующий файл в новый формат. Помимо этого, все обращающиеся к файлу программы должны быть изменены с целью соответствия новой структуре файла. Причем таких про¬грамм может быть очень много. Следовательно, программист должен прежде всего выявить все такие программы, а затем перепроверить и изменить их. Несовместимость форматов файлов Поскольку структура файлов определяется ко-дом приложений, она также зависит от языка программирования этого приложения. Например, структура файла, создан¬ного программой на языке СОВОL, может совершенно отличаться от структуры фай¬ла, создаваемого программой на языке С. Прямая несовместимость таких файлов за-трудняет процесс их совместной обработки. Фиксированные запросы/быстрое увеличение кол-ва приложений С точки зрения пользователя возможности файловых систем намного превосходят воз-можности ручных картотек. Соответственно возрастают и их требования к реализации но¬вых или модифицированных запросов. Однако файловые системы во многом зависят от про-граммиста, потому что все требуемые запросы и отчеты должны быть созданы именно им. В результате события обычно развивались по одному из следующих двух сценариев. Во мно¬гих организациях типы создаваемых запросов и отчетов имели фиксированную форму, и не было никаких инструментов создания незапланированных или произвольных за¬просов как к самим данным, так и к сведениям о том, какие типы данных доступны. В других организациях наблюдалось быстрое увеличение количества файлов и при¬ложений. В конечном счете наступал момент, когда сотрудники отдела ОД были просто не в состоянии справиться со всей этой работой с помощью имеющихся ресурсов. 2) БД. Определение. Назначение. Осн. хар-ки подхода Бд – организованная в соответствии с определенными правилами и поддерживаемая в памяти компьютера сов-ть данных, ха-щая актуальности состояний некоторой предметной области и используемая для удовлетворения инф-х потребностей пользователя. БД - Совместно используемый набор логически связанных д-х (и описание этих д-х), предназначенный для удовлетворения инф-х потребностей организации. Чтобы глубже вникнуть в суть этого понятия, рассмотрим его определение более внимательно. БД - это единое, большое хранилище данных, которое одно¬кратно определяется, а затем используется одновременно многими пользователями из разных подразделений. Вместо разрозненных файлов с избыточными данными, здесь все данные собраны вместе с минимальной долей избыточности. База данных уже не принадлежит какому-либо единственному отделу, а является общим корпора-тивным ресурсом. Причем база данных хранит не только рабочие данные этой организации, но и их описания. В совокупности, описание данных называется системным каталогом или словарем данных, а сами элементы описания принято называть метаданными, т.е. "данными о данных". Именно наличие самоописания данных в базе данных обеспечивает в ней независи¬мость между программами и данными. Пользователи объекта видят только его внешнее определение и не заботятся о том, как он определяет-ся и как функционирует. Одно из преимуществ такого подхода, а именно абстрагирования данных, за¬ключается в том, что можно изменить внутреннее определение объекта без каких-либо последствий для его пользователей. Аналогичным образом, в подходе с использованием баз данных, структура данных отделена от приложений и хранится в базе данных. Добавление но¬вых структур данных или изменение существующих никак не влияет на приложения, при условии, что они не зависят непосредственно от изменяемых компонентов. Напри¬мер, добавление нового поля в запись или создание нового файла никак не повлияет на работу имеющихся приложений. Однако удаление поля из используемого приложением файла повлияет на это приложение, а потому его также потребуется соответствующим образом модифици-ровать. Сущность – отдельный тип объекта организации (человек, место, вещь, событие), кот. Нужно представить в БД. Атрибут – Cв-во, кот. описывает некот. хар-ку описываемого объекта. Связь – это то, сто объединяет неск. сущностей 3) Системы баз данных. Компоненты СБД, их краткая характеристика. Бд – организованная в соответствии с определенными правилами и поддерживаемая в памяти компьютера сов-ть данных, ха-щая актуальности состояний некоторой предметной области и используемая для удовлетворения инф-х потребностей пользователя. Предметная область – часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Система БД относятся к организации компанентов, определяющих и регулирующих сбор, хранение, использование данных в среде БД. Основные компоненты СБД: Информационный компонент ПО Пользователи Аппаратное обеспечение Организационно-мет. Средства Информационный компонент – данные как начальная ед-ца БД, метаданные (данные о данных) Метаданные Описание данных м/д стадии разработки м/д ст. исполнения -внутрисистемные -пользовательские описание др. компанентов ИС Централизованное хранилище инф-и называют: Словарь; Энциклопедия; Каталог данных; Системный каталог; Как правило, эти понятия отличаются. Под «словарем данных» понимается сов-ть данных, отражающая писание структуры таблиц и их атрибутов. Аппаратное обеспечение – ЭВМ, устройства ввода, хранения, обработки инф-и. ПО: 1) СУБД – комплекс программных средств, предназначенных для создания и хранения на основе некоторой модели данных, обеспечение логической и физ. целостности содержащихся в ней данных, надежного и эффективного использования рес-ов, предоставление к ней санкционированного доступа прил-й и пользователя, а так же поддержка функций администратора БД. Среди компанент СУБД выделяют: • Ядро – средство создания БД, организации обработки и хранения данных. • Средства настрой системы • Средства тестирования • Утилиты • Трансляторы • Средства разработки приложений 2) ОС 3) ЯП 4)Прикл. ПО Пользователи Взяв за основу функциональные обязанности пользователя СБД выделяют: • Конечный п-ль • Администратор данных – специалист по управлению инф-ми ресурсами предприятия • Администратор БД – специалист в области ИТ, отвечающий за физ. Организацию БД и обеспечивающий необходимый уровень производительности системы • Прикладной программист. Организационно-мет ср-ва - инструкции и мет. Материалы, предназначенные для пользователей различных категорий взаимодействующих с БД, а также методики проектирования БД. 4) Администратор данных АД – специалисты по управлению инф-ми рес-ми предприятия Администратор данных отвечает за корпоративные информационные ресурсы, включая и некомпьютеризированные данные. На практике это часто связано с управлением данными, которые являются совместно используемым ресурсом для различных пользователей и прикладных программ данной организации. В разных организациях количество сотрудников, выполняющих функции АД, может отличать¬ся и обычно определяется размерами самой организации. В одних случаях администрирование данных может представлять собой отдельную функцио-нальную задачу, а в других — совмещаться с ад-министрированием базы данных. Задачи администратора БД ■ Выбор подходящих инструментов разработки. ■ Помощь в разработке корпоративных стратегий построения инф-ой с-ы, развития инф-ых технологий ■ Предварительная оценка осуществимости и планирование процесса созда¬ния базы данных. ■ Определение треб-ий организации к исполь-зуемым д-м. ■ Определение стандартов сбора данных и выбор формата их представления. ■ Оценка объемов данных и вероятности их роста. ■ Определение способов и интенсивности исп-ния д-х. ■ Определение правил доступа к данным и мер безопасности, соответствую¬щих правовым нормам и внутренним требованиям организации. ■ Концептуальное и логическое проектирование бд ■ Взаимодействие с АБД и разработчиками приложений с целью обеспечения соответствия создаваемых приложений всем существующим требованиям. ■ Обучение пользователей — изучение существующих стандартов обработки данных и юридической ответственности за их некорректное применение. ■ Обеспечение полноты всей требуемой доку-ментации ■ Поддержка словаря данных организации. ■ Взаимодействие с конечными пользователями для определения новых тре¬бований и разрешения проблем, связанных с доступом к данным и недос-таточной производительностью их обработки. 5) Администратор БД АБД – специалист в области ИТ, отвечающий за физ. организацию БД и обеспечивающий необходимый уровень производительности системы Деятельность АБД является в большей мере технической, чем деятельность АД, и предусматривает знание особенностей конкретных СУБД и операционных систем. Хотя основные обязанности АБД сконцентрированы на разработке и сопровождении систем с максимально полным использованием возможностей целевой СУБД, АБД меже в некоторой степени оказывает помощь АД. Количество персонала, выполняющего администрирование БД, может варьироваться и в значительной мере зависит от размера самой орга-низации. Задачи АБД ■ Оценка и выбор целевой СУБД. ■ Физическое проектирование базы данных. ■ Реализация физ. проекта БД в среде целевой СУБД. ■ Определение требований защиты и поддержки целостности данных. ■ Взаимодействие с разработчиками приложений БД ■ Разработка стратегии тестирования. ■ Обучение пользователей. ■ Ответственность за сдачу в эксплуатацию готового приложения БД. ■ Контроль тек-й производ-ти с-ы и соотв. на-стройка БД. ■ Регулярное резервное копирование. ■ Разработка требуемых механизмов восстанов-ления. ■ Обеспечение полноты используемой документации, включая материалы, разработанные внутри организации. - Составлены вручную Похожие работы:
Поделитесь этой записью или добавьте в закладки |
Полезные публикации |