База данных по гарантийным талонам

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

1.4. Реляционная схема базы данных

 

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

1. Каждая таблица состоит из  однотипных строк и имеет уникальное  имя.

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

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

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

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

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

5. Требования к аппаратному и системному программному обеспечению

 

При работе с БД, рекомендуется  соблюдать следующие требования к аппаратному и программному обеспечению компьютера:

1. Microsoft Windows XP/7/8;
2. Microsoft Access 2003/XP/2010/2012;
3. Процессор x86, начиная с 800 MHz и выше;
4. Оперативная память 64 Mb и выше;
5. Монитор VGA;
6. 10 Mb свободного места на жёстком диске;
7. Клавиатура;
8. Мышь.

Данное ПО не требует установки, для его работы необходимо:

• Установленный Microsoft Access 2003 или выше;
• Скопировать БД в локальную папку;
• Запустить БД.

 

2. Тестирование баз данных

 

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

Тестирование базы данных разделяется  на следующее типы:

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

 

3. Анализ качества и надежности баз данных

 

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

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

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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Проектирование баз данных

 

Проектирование баз данных - процесс решения класса задач, связанных с созданием баз данных.

Основные задачи проектирования баз данных:

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

В деловой или личной сфере часто  приходится работать с данными из разных источников, каждый из которых связан с определенным видом деятельности. Для координации всех этих данных необходимы определенные знания и организационные навыки. В настоящее время существует большое число систем управления базами данных, среди которых наиболее популярны MS Access, Paradox, dBase, FoxPro и другие. Microsoft Access объединяет сведения из разных источников в одной реляционной базе данных. Создаваемые формы, запросы и отчеты позволяют быстро и эффективно обновлять данные, получать ответы на вопросы, осуществлять поиск нужных данных, анализировать данные и печатать отчеты.

Ассess предоставляет большой выбор  способов хранения, отображения и  предоставления данных.

 

5. Основные этапы проектирования баз данных

 

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

Основные элементы данной модели:

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

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

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

На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:

1. основные объекты предметной области (объекты, о которых должна храниться информация в БД);
2. атрибуты объектов;
3. связи между объектами;
4. основные запросы к БД.

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

Между таблицами могут устанавливаться  различные связи. При связывании двух таблиц выделяют основную и дополнительную таблицы. Логическое связывание этих таблиц осуществляется с помощью ключа связи – поля связи. В зависимости от того, как определены поля связи основной и дополнительной таблиц, могут устанавливаться 4 вида связей: один к одному (1:1), один ко многим (1:М), многие к одному (М:1), многие ко многим (М:М). Связь М:М – самая слабая связь, тогда как оптимальным видом связи является связь, вида 1:М.