Анализ качества баз данных реферат

Обновлено: 30.06.2024

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 30.03.2015
Размер файла 50,7 K

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

1. Базы данных. Общие понятия

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

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

Пример простейшей базы данных в виде таблицы:

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

Программное обеспечение для управления и поддержки работоспособности БД называют системой управления базами данных (СУБД). СУБД осуществляют ввод, проверку, систематизацию, поиск и обработку данных, распечатку их в виде отчётов.

Среди множества СУБД наиболее часто используются пакеты программ dBASE разных версий, FoxBase +, FoxPro, Fox Soft Ware, Clipper, совместимые с dBASE по системе команд и файлам.

Например, БД, созданная в одной СУБД, может использоваться в другой совместимой с ней СУБД, имеющей формат файлов dBASE (*.dbf). Однако есть иные СУБД, например PARADOX и RBase, несовместимые с dBASE. Кроме СУБД для DOS, существуют СУБД, работающие в среде Windows, например Access, MS Works и др.

В основе БД лежит представление данных в виде таблиц. Основными понятиями в СУБД являются поля и записи. В полях содержатся данные. Поле характеризуется длиной. Совокупность всех полей в строке называется записью.

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

1.1 Типы данных

В СУБД можно обрабатывать следующие типы данных:

Дата календарная (Date).

Данные символьного типа -- это любая последовательность символов длиной не более 254.

Числовые данные делятся на 2 вида: целые и вещественные. Длина числового поля должна быть достаточной, чтобы поместились знак числа, целая часть, точка (десятичная) и дробная часть.

Значения календарной даты по умолчанию отображаются в Американском формате ММ/ЧЧ/ГГ (ММ-месяц, ЧЧ-число, ГГ-год). Длина этого поля установлена автоматически и равна 8.
Данные логического типа имеют значения ДА (YES) и НЕТ (NO).

В математической логике они называются Истина (True) и Ложь (False). В логических полях БД используются только первые буквы латинских слов Y,T,N,F. Длина логического поля равна 1.
В поле примечаний отмечается признак, который указывает, что к записи прилагается дополнительный фрагмент текста.

1.2 Структура базы данных

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

Каждое поле БД характеризуется рядом параметров.

количество десятичных знаков

СУБД поддерживает пять типов полей:

СИМВОЛЬНЫЙ -- поля этого типа предназначены для хранения в них информации, которая рассматривается как строка символов и может состоять из букв, цифр, знаков препинания и т.п.

ЧИСЛОВОЙ -- поля этого типа предназначены только для хранения чисел.

ДАТА -- поля этого типа предназначены для хранения каких-либо дат в фиксированном формате: число, месяц, год.

ЛОГИЧЕСКИЙ -- поля этого типа предназначены для хранения альтернативных значений вида "ДА" -- "НЕТ" или "ПРАВДА" -- "ЛОЖЬ". При этом значению "ДА" соответствует нахождение в поле символа "Т", а значение "НЕТ" -- символа "F".

ПРИМЕЧАНИЕ (Memo) -- поля этого типа используются для хранения фрагментов текста (примечаний).

Длина поля -- это ширина вертикального столбца таблицы в символах.

Длина полей СИМВОЛЬНОГО типа представляют собой количество символов, которое Вы хотите уместить в поле.

Длина поля ЧИСЛОВОГО типа равна количеству десятичных разрядов числа, умещающегося в поле, включая знак числа, десятичную точку, целую и дробную часть. Например, если Вы описываете значение "-546.78", то длина равна 7.

Длина ЛОГИЧЕСКОГО поля всегда равна 1, так как его значение "T" или "F".

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

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

2. Понятие СУБД

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

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

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

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

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

Рис.1 Состав СУБД.

2.1 Классификация СУБД

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

Однако в некоторых случаях доступные СУБД общего назначения не позволяют добиться требуемой производительности и/или удовлетворить заданные ограничения по объёму памяти, предоставляемой для хранения БД. Тогда приходится разрабатывать специализированную СУБД для данного конкретного применения. Примером специализированной СУБД может быть система IMBASE, используемая для автоматизации проектных и конструкторских разработок.

Важнейшим классификационным признаком СУБД является тип модели данных, поддерживаемый СУБД. По этому признаку СУБД делятся на:

· Иерархические. Первой иерархической СУБД была система IMS (Information Management System) компании IBM,коммерческое распространение которой началось в 1968 г.;

· Сетевые. Первой сетевой СУБД считается система IDS (Integrated Data Store), разработанная компанией General Electric немножко позже системы IMS;

· Реляционные. Первые коммерческие реляционные СУБД от компании IBM, Oracle Corporation, Relation Technology Inc. и других поставщиков появились в начале 80-х годов. Реляционные СУБД просты в использовании, повышают производительность программистов при разработке прикладных программ, хорошо приспособлены для работы в архитектуре клиент/сервер, позволяют параллельную обработку БД, хорошо приспособлены к графическим интерфейсам. Реляционные СУБД продолжают совершенствоваться, предоставляя пользователю возможность решать всё более сложные задачи;

· Объектно-реляционные (постреляционные). Объектно-реляционные СУБД продолжают использовать стандартный язык запросов для реляционных БД - SQL, но с объектными расширениями;

· Объектно-ориентированные. В основе объектно-ориентированных СУБД лежит объектно-ориентированная модель обработки данных.

· Многомерные, в основе которых лежит многомерная модель данных.

На самом общем уровне все СУБД можно разделить на:

· Профессиональные (промышленные), которые представляют собой программную основу для разработки автоматизированных систем управления крупными экономическими объектами. На их базе создаются комплексы управления и обработки информации крупных предприятий, банков или даже целых отраслей. В настоящее время характерными представителями профессиональных СУБД являются такие программные продукты: Oracle, DB2, Sybase, Informix, Inqres, Progress.

· Персональные (настольные). Это программное обеспечение, ориентированное на решение задач локального пользователя или компактной группы пользователей и предназначенная для использования на персональном компьютере, это объясняет их второе название - настольные. К ним относятся DBASE, Fox Base, Fox Pro, Clipper, Paradox, Access.

В настоящее время среди СУБД выделяют СУБД (условно говоря) промежуточные между профессиональными и персональными. SQL Windows/SQL Base, Interbase, Microsoft SQL Server.

Подобные документы

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

презентация [4,3 M], добавлен 21.02.2011

реферат [27,5 K], добавлен 10.01.2011

Рассмотрение совокупности программ и языковых средств (специальных языков описания и манипулирования данными), предназначенных для создания, ведения и использования баз данных. Определение языков общения. Исследование принципов построения банка данных.

реферат [56,9 K], добавлен 07.08.2017

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

дипломная работа [2,9 M], добавлен 04.11.2012

Алгоритмы обработки массивов данных. Система управления базами данных. Реляционная модель данных. Представление информации в виде таблицы. Система управления базами данных реляционного типа. Графический многооконный интерфейс.

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

Работа состоит из 1 файл

Характеристики качества баз данных.docx

Характеристики качества баз данных

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

1 Системный анализ и требования к качеству

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

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

При комплексном анализе качества баз данных не всегда удается четко разделить требования и значения характеристик качества для каждого из этих объектов.

Одна и та же система управления базой данных (СУБД) может обрабатывать различные по структуре, составу и содержанию данные, а одни и те же данные могут управляться программными средствами различных СУБД. Хотя эти компоненты тесно взаимодействуют при реализации конкретной прикладной БД, первоначально при проектировании они создаются или выбираются практически независимо и могут рассматриваться в их жизненном цикле (ЖЦ) как два объекта, которые различаются:

  • номенклатурой и содержанием показателей качества, определяющих их назначение, функции и потребительские свойства;
  • технологией и средствами автоматизации разработки и обеспечения всего ЖЦ каждого объекта;
  • категориями специалистов, обеспечивающих создание, эксплуатацию или применение компонентов БД;

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

2 Компоненты системного анализа

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

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

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

В универсальных СУБД спектр характеристик качества шире, что позволяет соответственно расширять сферу применения конкретного типа СУБД.

Однако и для них существуют области приоритетного, или наиболее эффективного использования.

За основу принята номенклатура и содержание стандартизированных

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

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

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

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

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

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

3 Конструктивные характеристики качества информации БД

К конструктивным характеристикам качества информации БД в целом можно отнести, с некоторой корректировкой и уточнением понятий, субхарактеристик и атрибутов, практически все стандартизированные показатели качества ПС, которые представлены в ISO 9126.

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

Меры и шкалы для оценивания конструктивных характеристик могут

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

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

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

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

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

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

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

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

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

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

Эффективность использования ресурсов ЭВМ при системном

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

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

Как анализировать базу данных


Определяем связи в БД

Прежде чем писать SQL-запросы и анализировать результаты, надо разобраться в данных и схемах.

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

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

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

Рекомендую все выводы конспектировать в документации. Тогда в поиске нужной информации вы будете просматривать небольшой пул таблиц, в котором, скорее всего, найдете ответ.

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

Ответьте на вопросы:

  • информация за какой период хранится в таблице;
  • какие в ней идентификаторы (поля ids);
  • какие события содержит таблица;
  • хранится ли там информация по сущностям. Если да — просмотрите ее с агрегацией по разным признакам (например, верифицированные пользователи и нет, удаленные и нет).

Если идентификаторов (ids) много, постарайтесь найти для всех таблицы-словари. Можете ориентироваться на название поля перед id и искать таблицу с похожим названием. Например, если вы увидели в таблице ключ user_id, постарайтесь найти таблицы с 'users' в названии. Скорее всего, расшифровка будет лежать в одной из них.

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

Когда данные изучены и определены, можно приступать к созданию SQL-запроса.

Составляем схему результирующего набора

Обычно задача аналитика не включает список всех данных, которые надо получить.

Но так как SQL-запрос выдаст вам набор из метрик и показателей, надо продумать его заранее.

Когда подготовите схему, спросите себя:

  • сколько таблиц участвует в запросе?
  • возможно ли дублирование данных при соединении этих таблиц?
  • удастся ли избежать его с помощью оператора distinct или придется прибегать к подзапросам / CTE.
  • какой объем информации предстоит запросить у базы? Можно ли его уменьшить? Нужны ли дополнительные ограничения?
  • какие данные должны быть образующими для запроса? Важно ли учесть все сущности словаря или, наоборот, данные обо всех активностях (даже если их расшифровки нет в словарях)?



Пример заметок перед созданием запроса в новой базе данных

Пишем сложный SQL query

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

Поэтому возьмите одного пользователя или одно событие и проверьте результат последовательным набором простых select + where.

Не применяйте сложные вычисления, в которых можно совершить ошибку (windows functions, having, коррелирующие подзапросы). Ограничьтесь простым select c фильтром. Если вы прошли эту цепочку и получили тот же результат, что и ваш сложный запрос, — высока вероятность, что он написан верно.

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

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

Как работать с комплексными SQL-запросами:

  • проверяйте корректность выполнения каждой части — гораздо проще отловить ошибку на промежуточном этапе, чем в конце;
  • не пишите слишком много вложенных друг в друга подзапросов. Даже вам будет трудно разобраться в таком коде через пару дней. Старайтесь выделять логические части в CTE;
  • старайтесь не мешать CTE и подзапросы с вложенностью больше трех. Применяйте в коде что-то одно, выносите все сложные части в общие табличные выражения или пишите подзапросы с большой вложенностью;
  • ставьте фильтры на первых этапах. Чем раньше вы ограничите выборку, тем меньше данных придется вычислять в следующих операциях;
  • не переименовывайте столбцы и таблицы без причины. Не стоит давать таблице alias ради сокращения ее названия на 2 символа. Не переименовывайте столбцы из таблиц, к которым не применялась обработка. Используйте псевдонимы при необходимости. Например, если название таблицы очень длинное. Тип псевдонима по первой букве таблицы можно применить, если все в вашей компании знают, что s — sales table. Но если это может быть sales_profit, sales_roi или sales_partners, лучше оставить название без изменения;
  • оставляйте комментарии;
  • не забывайте о форматировании. Его отсутствие может сделать скрипт нечитаемым и привести к неверной интерпретации другим членом команды. Поэтому делайте табуляцию, отступы и не пишите все сплошным текстом.
  • выносите отдельно все повторяющиеся части запроса, чтобы к ним можно было обратиться несколько раз, не переписывая заново.

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

Базы данных, основные модели их организации [15.12.13]

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

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

База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области,

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

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

Краткие характеристики персонального компьютера и программного обеспечения, использованных для выполнения и оформления данной работы: процессор: Intel 3,3 Ггц / оперативная память -2 Гб/ HDD – 500 Гб/ видеокарта – ATI HD5770 1024Мб/ DVD +/- RW / клавиатура / мышь/ ОС Windows Vista / Microsoft Office 2010: Word, Excel/.

II. Теоретическая часть

2.1. Базы данных и системы управления базами данных

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

Компьютеры хранят данные в файлах. Файл представляет собой набор записей, посвященных некой общей теме. Каждая запись состоит из данных, которые разделены на поля. В тра­диционной файловой системе конкретные множества файлов создаются и обрабатываются конкретными приложениями. В системе с базой дан­ных они не привязаны к конкретным поддер­живающим их приложениям.

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

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

Рис 1.1. Система с базой данных

Рис 1.1. Система с базой данных

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

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

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

Таким образом, СУБД обеспечивает следующие возможности:

  • интеграцию и совместное использование данных различными прило­жениями;
  • способность поддерживать разнообразные представления одних и тех же данных;
  • управление параллельным доступом к данным;
  • гарантию безопасности и целостности данных.

Система с базой данных состоит из следующих компонентов.

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

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

Таким образом, систему с базой данных можно представить в виде последовательности уровней (рис. 1.2).

Рис. 1.2. Уровни системы с базой данных

Рис. 1.2. Уровни системы с базой данных

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

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

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

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

Чтобы создать словарь данных, нужно задать полное описание логи­ческих объектов базы данных, которые необходимо сохранить. Такое описание носит название концептуальной схемы.

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

Представление данных - это отображение данных в базе данных (на концептуальном уровне), которое необходимо конкретному приложению. Одно и то же множество объектов базы данных может отображаться в различные представления. Описание соответствия между представлением и множеством объектов базы данных называется его определением. Все определе­ния представлений хранятся в словаре данных и становятся полноправ­ными объектами базы данных. Это дает возможность нескольким прило­жениям использовать одно и то же представление. Множество всех определений представлений образуют так называемый внешний уровень базы данных — интерфейс между базой данных и ее пользователями. Ес­ли концептуальная схема базы данных модифицируется, то все определе­ния представлений, затронутых этой модификацией, необходимо будет переписать так, чтобы представление осталось для своих пользователей неизменным даже в том случае, если оно теперь основывается на совер­шенно иной части логической базы данных. Таким образом, приложения отстраняются от модификации базы данных на логическом уровне. Это называется логической независимостью данных.

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

Физическое хранилище крупной базы данных часто подвергается об­новлениям и изменениям, чтобы повысить производительность и отра­зить изменения, происходящие в реальном мире. На самом нижнем уровне СУБД должна установить соответствие между представлением ба­зы данных в виде концептуальной схемы и ее физическим представлени­ем. Это отображение называется внутренним уровнем системы с базой данных. Он является интерфейсом между СУБД и системой компьютера, на котором она выполняется. Если физическое хранилище базы данных меняется, то СУБД должна на внутреннем уровне вновь установить соот­ветствие концептуальной схемы новому физическому представлению. Сама концептуальная схема должна остаться неизменной. Это позволит приложениям продолжать работать так, словно ничего не изменилось.

Таким образом, СУБД состоит из трех уровней: множества отображе­ний концептуального уровня в представления пользователей, самого концептуального уровня и отображения концептуального уровня в физи­ческое хранилище. Эти три уровня называются внешним, концептуаль­ным и внутренним уровнем соответственно (рис. 1.3).

Рис. 1.3. Уровни СУБД

Рис. 1.3. Уровни СУБД

2.2. Типы баз данных

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

Иерархические базы данных:

В 1968 году компания IBM предложила своим клиентам систему управления информацией (IMS). В IMS база данных была концептуально представлена в виде иерархии. Записи были организованы в наборы, которые связывались друг с другом связями.

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

Сетевые базы данных:

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

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

Реляционные базы данных:

Реляционная модель базы данных была впервые предложена Коддом в 1970 году. Она существенно отличалась от описанных ранее моделей и в 80-х получила всеобщее признание как наиболее согласованная и удобная модель разработки СУБД.

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

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

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

Объектно-ориентированные базы данных:

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

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

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

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

2.3. Вывод

Глобальная интеграция информационных систем, огромные темпы наращивания объемов данных и требования одновременной работы с ними различным пользователям – приводит к организации данных в системы баз данных.

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

III. Практическая часть

3.1. Содержание задачи

Рассмотрим задачу. Вариант 5.

Читайте также: