Шпаргалки по БД (базам данных) и СУБД (системам управления базами данных)

1) Файловые системы. Недостатки.

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

Недостатки

■ Разделение и изоляция данных.

■ Дублирование данных.

■ Зависимость от данных.

■ Несовместимость файлов.

■ Фиксированные запросы/быстрое увеличение количества приложений.

Разделение и изоляция данных Когда данные изолированы в отдельных файлах, доступ к ним весьма затруднен. На-пример, для создания списка всех домов, отвечающих требованиям потенциальных арендаторов, предварительно нужно создать временный файл со списком арендаторов, желающих арендовать недвижимость типа «дом». Затем в файле следует осуществить поиск объектов недвижимости типа «дом» с арендной платой ниже установленного арендатором максимума. Выполнять подобную обработку данных в файловых системах достаточно сложно. Для извлечения соответствующей поставленным условиям информации программист должен организовать синхронную обработку двух файлов. Трудности существенно возрастают, когда необходимо извлечь данные из более чем двух файлов.

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

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

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

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

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

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

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

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

2) БД. Определение. Назначение. Осн. хар-ки подхода Бд — организованная в соответствии с определенными правилами и поддерживаемая в памяти компьютера сов-ть данных, ха-щая актуальности состояний некоторой предметной области и используемая для удовлетворения инф-х потребностей пользователя.

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

Чтобы глубже вникнуть в суть этого понятия, рассмотрим его определение более внимательно. БД — это единое, большое хранилище данных, которое однократно определяется, а затем используется одновременно многими пользователями из разных подразделений. Вместо разрозненных файлов с избыточными данными, здесь все данные собраны вместе с минимальной долей избыточности. База данных уже не принадлежит какому-либо единственному отделу, а является общим корпора-тивным ресурсом. Причем база данных хранит не только рабочие данные этой организации, но и их описания. В совокупности, описание данных называется системным каталогом или словарем данных, а сами элементы описания принято называть метаданными, т. е. «данными о данных». Именно наличие самоописания данных в базе данных обеспечивает в ней независимость между программами и данными.

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

Сущность — отдельный тип объекта организации (человек, место, вещь, событие), кот. Нужно представить в БД. Атрибут — Cв-во, кот. описывает некот. хар-ку описываемого объекта. Связь — это то, сто объединяет неск. сущностей

3) Системы баз данных. Компоненты СБД, их краткая характеристика.

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

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

Система БД относятся к организации компанентов, определяющих и регулирующих сбор, хранение, использование данных в среде БД.

Основные компоненты СБД:

Информационный компонент ПО Пользователи Аппаратное обеспечение Организационно-мет. Средства

Информационный компонент — данные как начальная ед-ца БД, метаданные (данные о данных) Метаданные Описание данных м/д стадии разработки м/д ст. исполнения

— внутрисистемные

— пользовательские описание др. компанентов ИС

Централизованное хранилище инф-и называют:

Словарь;

Энциклопедия;

Каталог данных;

Системный каталог;

Как правило, эти понятия отличаются.

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

Аппаратное обеспечение — ЭВМ, устройства ввода, хранения, обработки инф-и.

ПО:

1) СУБД — комплекс программных средств, предназначенных для создания и хранения на основе некоторой модели данных, обеспечение логической и физ. целостности содержащихся в ней данных, надежного и эффективного использования рес-ов, предоставление к ней санкционированного доступа прил-й и пользователя, а так же поддержка функций администратора БД.

Среди компанент СУБД выделяют:

• Ядро — средство создания БД, организации обработки и хранения данных.

• Средства настрой системы

• Средства тестирования

• Утилиты

• Трансляторы

• Средства разработки приложений

2) ОС

3) ЯП

4)Прикл. ПО Пользователи Взяв за основу функциональные обязанности пользователя СБД выделяют:

• Конечный п-ль

• Администратор данных — специалист по управлению инф-ми ресурсами предприятия

• Администратор БД — специалист в области ИТ, отвечающий за физ. Организацию БД и обеспечивающий необходимый уровень производительности системы

• Прикладной программист.

Организационно-мет ср-ва

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

4) Администратор данных АД — специалисты по управлению инф-ми рес-ми предприятия Администратор данных отвечает за корпоративные информационные ресурсы, включая и некомпьютеризированные данные. На практике это часто связано с управлением данными, которые являются совместно используемым ресурсом для различных пользователей и прикладных программ данной организации. В разных организациях количество сотрудников, выполняющих функции АД, может отличаться и обычно определяется размерами самой организации.

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

Задачи администратора БД

■ Выбор подходящих инструментов разработки.

■ Помощь в разработке корпоративных стратегий построения инф-ой с-ы, развития инф-ых технологий

■ Предварительная оценка осуществимости и планирование процесса создания базы данных.

■ Определение треб-ий организации к исполь-зуемым д-м.

■ Определение стандартов сбора данных и выбор формата их представления.

■ Оценка объемов данных и вероятности их роста.

■ Определение способов и интенсивности исп-ния д-х.

■ Определение правил доступа к данным и мер безопасности, соответствующих правовым нормам и внутренним требованиям организации.

■ Концептуальное и логическое проектирование бд

■ Взаимодействие с АБД и разработчиками приложений с целью обеспечения соответствия создаваемых приложений всем существующим требованиям.

■ Обучение пользователей — изучение существующих стандартов обработки данных и юридической ответственности за их некорректное применение.

■ Обеспечение полноты всей требуемой доку-ментации

■ Поддержка словаря данных организации.

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

5) Администратор БД АБД — специалист в области ИТ, отвечающий за физ. организацию БД и обеспечивающий необходимый уровень производительности системы Деятельность АБД является в большей мере технической, чем деятельность АД, и предусматривает знание особенностей конкретных СУБД и операционных систем. Хотя основные обязанности АБД сконцентрированы на разработке и сопровождении систем с максимально полным использованием возможностей целевой СУБД, АБД меже в некоторой степени оказывает помощь АД. Количество персонала, выполняющего администрирование БД, может варьироваться и в значительной мере зависит от размера самой орга-низации.

Задачи АБД

■ Оценка и выбор целевой СУБД.

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

■ Реализация физ. проекта БД в среде целевой СУБД.

■ Определение требований защиты и поддержки целостности данных.

■ Взаимодействие с разработчиками приложений БД

■ Разработка стратегии тестирования.

■ Обучение пользователей.

■ Ответственность за сдачу в эксплуатацию готового приложения БД.

■ Контроль тек-й производ-ти с-ы и соотв. на-стройка БД.

■ Регулярное резервное копирование.

■ Разработка требуемых механизмов восстанов-ления.

■ Обеспечение полноты используемой документации, включая материалы, разработанные внутри организации.