Этапы проектирования баз данных реферат

Содержание:

Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.

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

При проектировании таблиц рекомендуется руководствоваться следующими основными принципами:

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

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

Как задать первичный ключ базы данных Access

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

Основные задачи:

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

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

  1. Концептуальное (инфологическое) проектирование.

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

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

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

Чаще всего концептуальная модель базы данных включает в себя:

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

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

  • Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
  • Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
  • Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

Поскольку использование метода «сущность-связь» является комбинированным способом проектирования на данном этапе, он чаще других становится приоритетным.

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

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

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

После этого производится спецификация атрибута, спецификация связей в локальном представлении (с разделением на факультативные и обязательные) и объединение локальных представлений. При числе локальных областей до 4-5 их можно объединить за один шаг. В случае увеличения числа бинарное объединение областей происходит в несколько этапов.

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

  1. Логическое (даталогическое) проектирование.

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

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

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

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

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

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

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

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

  1. Физическое проектирование.

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

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

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

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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

Выбор системы управления и программных средств БД.

От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:

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

Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.

Источники:

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

http://inf.e-alekseev.ru/text/Etapy_bd.html

https://finswin.com/projects/proektirovanie/ehtapy-bazy-dannyh.html

СПИСОК ДЛЯ ТРЕНИРОВКИ ССЫЛОК

  • Международное разделение труда: понятие, основные виды, исторические этапы развития
  • Гипертекстовые и мультимедийные информационные технологии (МУЛЬТИМЕДИА КОНТЕНТ В МОБИЛЬНЫХ СЕТЯХ)
  • Субъекты информационного права
  • Уголовная ответственность за правонарушения в информационной сфере (ПРИЗНАКИ, СОСТАВ И ХАРАКТЕРИСТИКА ПРАВОНАРУШЕНИЙ В ИНФОРМАЦИОННОЙ СФЕРЕ)
  • Основные понятия управления проектами («Двойственная» организационная структура)
  • Характеристика эффективности спортивной техники (организация и планирование самостоятельных занятий по развитию физических качеств)
  • Формирование и развитие команды проекта (Принципы формирования команды проекта.)
  • Принцип диспозитивности
  • КАК ВЫ ПОНИМАЕТЕ ПОНЯТИЕ «НЕДОБРОСОВЕСТНАЯ КОНКУРЕНЦИЯ»
  • Коммерческие риски в торговом деле
  • Управление качеством проекта (менеджмент качества проекта)
  • Сравнение топологии сетей (Существует бесконечное число способов соединения компьютеров)

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПРАВОСУДИЯ»

РЕФЕРАТ

по дисциплине       Информационные технологии в деятельности суда

«Проектирование баз данных, его этапы и задачи»

Москва, 2021

СОДЕРЖАНИЕ

ВВЕДЕНИЕ …………………………………………………………………………………………………..3

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

        2. Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных……………………………………………………………………………………………..7

        2.1 Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных………………………………………………………………………………………………………8

        2.2 Бизнес-модель этапа проектирования – создание физической модели реляционной базы данных…………………………………………………………………………………………………………10

        2.3 Бизнес-модель этапа проектирования – создание физической модели реляционной базы данных: учет влияния транзакций……………………………………………………………………………………………………11

ЗАКЛЮЧЕНИЕ ……………………………………………………………………………………………12

СПИСОК ЛИТЕРАТУРЫ……………………………………………………………………………..13

ВВЕДЕНИЕ

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

Примеры функциональных требований: выдача отчетов по продажам по регионам; выдача отчетов по продажам по кварталам; автоматический расчет скидок на товары при увеличении объема закупаемой партии и т.п.

Примеры ограничений: максимальное время, отпущенное на проект; количество денежных средств, которое можно на него потратить.

В эксплуатации база данных и ее окружение должны удовлетворять набору требований по ряду укрупненных (интегрированных) параметров, таких как:

  • функциональность и адаптируемость;
  • производительность обработки транзакций;
  • пропускная способность;
  • время реакции;
  • безопасность.

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

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

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

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

Проектирование объектов базы данных (таблицы, представления, индексы, триггеры, хранимые процедуры, функции, пакеты) для представления данных предметной области в базе данных.

Проектирование баз данных под конкретную вычислительную среду или информационную технологию (архитектура «клиент-сервер», параллельные архитектуры, распределённая вычислительная среда).

Известно, что база данных:

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

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

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

Рассмотрим типовую бизнес-модель процесса проектирования базы данных. На рис. 3.1 приведена контекстная диаграмма процесса проектирования базы данных.

Рис. 3.1. Контекстная диаграмма процесса проектирования базы данных

Как видно из рисунка, на вход процесса проектирования базы данных подаются:

  • информационная модель предметной области базы данных: диаграммы «сущность-связь» (ER-диаграммы);
  • функциональная модель предметной области базы данных: бизнес-модель процессов, диаграммы потока данных (DF-диаграммы), диаграммы состояний, – диаграммы жизненных циклов сущностей, спецификации на системы (требования), бизнес-правила;
  • общесистемные требования и ограничения;
  • задачи обратного влияния.

На выходе процесса проектирования базы данных формируются следующие результаты:

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

По требованию может быть разработана и другая документация.

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

Рис. 3.2

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

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

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

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

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

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

2. Бизнес-модель процесса проектирования базы данных: сбор и анализ входных данных

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

Рис. 3.3.

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

Такими задачами являются:

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

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

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

2.1. Бизнес-модель процесса проектирования реляционной базы данных: создание логической модели базы данных

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

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

Результатом проектирования логической модели базы данных является нормализованная схема отношений базы данных. Отметим, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных, не предусмотренные в информационной модели предметной области, например связывающая сущность при нормализации отношения со степенью связи “многие-ко-многим”. Иногда на этом этапе принимается решение о выборочной денормализации отношений.

На рис. 3.4-рис. 3.5 представлены бизнес-модели процессов создания логической модели базы данных, нормализации сущности предметной области и нормализации отношений логической модели базы данных соответственно.

Рис. 3.4. Бизнес-модель процесса создания логической модели базы данных

Рис. 3.5. Бизнес-модель процесса нормализации отношения

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

2.3. Бизнес-модель этапа проектирования – создание физической модели реляционной базы данных

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

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

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

Принять решение о способе поддержки ссылочной целостности в базе данных. Эта задача решается в четыре этапа:

  • идентифицировать первичные ключи каждой таблицы;
  • построить индексы первичного ключа;
  • определить внешние ключи в дочерних таблицах, если необходимо;
  • построить команды SQL, которые идентифицируют внешние ключи в дочерних таблицах и правила поддержки ссылочной целостности;

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

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

2.4. Бизнес-модель этапа проектирования – создание физической модели реляционной базы данных: учет влияния транзакций

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

  1. Корнеев В.В., Гараев А.Ф., Васютин С.И., Райх В.В. Базы данных. Интеллектуальная обработка информации – М.: Нолидж, 2000
  2. Туманов В.Е. Основы проектирования реляционных баз данных. – БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий – ИНТУИТ.ру, 2007

Реферат: Создание базы данных

Этапы создания базы данных

В файловых системах одновременная работа нескольких пользователей, связанная с модификацией данных в файле либо вообще не реализовывалась, либо была замедлена. Эти недостатки привели к разработке новых подходов к управлению информации. Этот подход был реализован в рамках новых программных средств и называется системой управления базой данных (СУБД), а сами хранилища информации назывались базами данных и банками данных. Одним из первых этапов создания базы данных – это были большие ЭВМ. Первые СУБД были даны в эксплуатацию фирмой IBM в конце 60-х годов. Эта СУБД была связана с организацией базы данных на больших ЭВМ (360) и ЕС (Единая система). Здесь базы данных хранились во внешней памяти центрального ЭВМ. Пользовательскими задачами были запуск данных в пакетном режиме. Мощные операционные системы параллельно обеспечивали множество задач. Эти системы можно было отнести к системе распределённого доступа, потому что база данных была централизованной. Хранилась на установленной внешней памяти одной из центрального ЭВМ, а доступ к ней поддерживался от многих пользователей и задач.

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

Второй этап – это эпоха персональных компьютеров. В это время появились программы, которые назывались СУБД и позволяли хранить значительный объём информации. Они имели удобный интерфейс для заполнения базы данных. Они позволяли автоматизировать множественные функции, которые ранее велись вручную. Первые базы данных на компьютерах были недолговечны, т.е. они не учитывали взаимосвязи реальных объектов и спрос на удобные программы СУБД. Это привело к созданию настольных СУБД. При этом каждый разработчик разрабатывал собственные СУБД , используя стандартные языки программирования и таким образом каждый раз приходилось набранные данные переносить на более новый СУБД. Это было одно из основных недостатков этой эпохи. Яркие представители этой эпохи были: dbase, FoxPro, clipper, Paradox.

Третий этап распределения базы данных. В этом этапе появилось большое количество локальных сетей, все больше информации передаются между компьютерами и встаёт задача о согласовании данных , хранящихся и обрабатываемых в разных местах, но которые логически связаны друг с другом. Решение этой задачи приводит к появлению распределённой базы данных, сохраняющих преимущество всех настольных СУБД, но в тоже время позволяющих организовать параллельную обработку информации. Именно на этом этапе были начаты работы связанные с концепцией объектно ориентированной базы данных (SQL). Для манипулирования данными на этом этапе был использован SQL и технологии по обмену данными между СУБД, к которым можно отнести ODBC (open database connectivity). Именно на этом этапе были представлены MsAccess, MsSQL,ORCL и т.д.

Четвёртый этап- перспективы развития СУБД. Он характерен новой технологией доступа к данным intronet. При этом отпадают необходимости использования специального клиентского программного обеспечения. Для работы с удалённой базой данных используют стандартные браузеры Интернет Explorer и т.д. При этом встроенный в загруженный пользователями html страницы код, написан на языках java, JavaScript отлаживает все действия пользователя и транслируют их в низкоуровневые SQL запросы. Таким образом выполняется клиентская программа. Удобства такого подхода позволило использовать его не только в удалённые базы данных, но и в локальных сетях предприятий.

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

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

1) Управление данными. Задачами управления данных являются подготовка и контроль данных, внесения данных в базу данных, обеспечение целостности и секретности данных.

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

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

Этапы проектирования базы данных

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

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

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

-словесное описание данных и их взаимосвязи.

Инфологический уровень данных

-строится инфологическая и логическая модель без описания СУБД.

Логический уровень данных

-отражает информационные логические модели на базе данных подчиняющихся СУБД.

Внутренний уровень данных

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

Понятие модели данных

Существую 3 вида модели:

1) Иерархическая

2) Сетевая

3) Реляционная

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

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

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

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

№ страницы

Фамилия

Имя

Год рождения

Место рождения

8009

Мамедов

Рза

1990 г.

Баку

Домен

→ атрибут

кортёж→

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

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

Для построения реляционной модели используют табличный способ представления данных типа отношения. Наименование единица в реляционной модели- это отдельная атомарная для данных моделей. Множество атомарных значений формируют домен. Отношением на доменах D1,D2…….Dn составленных из заголовка n тела отношений. Заголовок состоит из множества атрибутов ,A1…….An, в которых существует однозначное соответствие между этими атрибутами Ai и определяют их доменами Di. Тело отношения состоит из меняющейся во времени множества кортежей, где каждый кортеж в свою очередь состоит из множества пар атрибут -значений (Ai:Vi). Для любой заданной пары атрибут –значением Vi является значением из единственного домена Di, который связан с атрибутом Ai. Степень отношения – это число его атрибутов. Отношения – это число его кортежей. Ключом отношений является его уникальность. Т.е. никакие два различных кортежа не имеют одного и того же значения для входящих в ключ атрибутов. Ни один из атрибутов, входящий в ключ, не может быть исключён без нарушения уникальности. Каждое отношение обладает хотя бы одним ключом. Один из возможных ключей принимают за первичный, остальные называются альтернативными ключами. Основная цель проектирования базы данных- сокращение избыточности базы данных и экономии объёма используемой памяти. Нормализация – это разделение таблицы на две и более обладающие лучшими свойствами при включении изменений и удаление данных.

страхование база данный

ПРАКТИЧЕСКАЯ ЧАСТЬ

Рассмотрим данные для создания базы данных на тему «Страхование населения». Создаем базу в реляционной модели базы данных.

Описание данной задачи: «Руководство страховой компании заказало разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных, о видах страховок, их стоимость, о совершенных сделках, о клиентах, сроках действия страховки. Система должна выдавать отчеты по запросу менеджера: прайс лист по видам страховки, бланк страхования, информацию о клиентах».

Для начала требуется создать таблицу, включающую все вышеуказанные данные в себя. Таблица создается с помощью “создание таблицы в режиме конструктора”:

После создания таблицы создаём форму для данной таблицы при помощи “мастера создания форм”. Добавляем всё содержимое таблицы, создаём внешний вид формы, требуемый стиль, задаём имя формы и она готова:

Затем создаём требуемые в данной задаче запросы в режиме SQL:

SELECT Общая. номер, Общая.[ИФО клиента], Общая.[Год рождения], Общая. Адресс FROM Общая;

SELECT Общая.[вид страховки], Общая.[стоимость страховки] FROM Общая;

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

Создание отчёта с помощью мастера→ выбираем поля для отчёта→ добавляем уровни группировок и расставляем в нужной последовательности данные→ задаём требуемый порядок сортировки→ выбираем вид макета для отчёта→ выбираем требуемый стиль→ задаём имя и отчёт готов:

Страница № 1.1

Страница № 1.2

Страница № 1.3

Так же и второй отчёт на запрос прайс листа по видам страховок:

Страница № 2.1

Страница № 2.2

Таким образом наше задание выполнено и завершено.

Содержание

ВВЕДЕНИЕ……………………………………………………………………………………………………3

1.РАЗРАБОТКА
ПЛАНА БАЗЫ
ДАННЫХ……………………………………………………..4

2.1.
ИНФОЛОГИЧЕСКОЕ
МОДЕЛИРОВАНИЕ……………………………………………..8

2.2.
ДАТАЛОГИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ……………………………………………..9

3.1.ЦЕЛОСТНОСТЬ
БАЗЫ
ДАННЫХ…………………………………………………………..10

3.2.
ПРОВЕРКА ЦЕЛОСТНОСТИ БАЗЫ
ДАННЫХ……………………………………..10

4.ЭТАПЫ
ПРОЕКТИРОВАНИЕ БАЗЫ
ДАННЫХ…………………………………………12

4.1.КОНЦЕПТУАЛЬНОЕ
ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ………………….12

4.2.ЛОГИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ БАЗЫ
ДАННЫХ…………………………..12

4.3.ФИЗИЧЕСКОЕ
ПРОЕКТИРОВАНИЕ БАЗЫ
ДАННЫХ…………………………..13

ЗАКЛЮЧИНИЕ……………………………………………………………………………………………15

СПИСОК
ЛИТЕРАТУРЫ………………………………………………………………………………17

Введение

Жизненный
цикл базы данных

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

Жц бд включает в себя следующие основные этапы:

  • планирование
    разработки базы данных;

  • определение
    требований к системе;

  • сбор
    и анализ требований пользователей;

  • проектирование
    базы данных:

    • концептуальное
      проектирование базы данных;

    • логическое
      проектирование базы данных;

    • физическое
      проектирование базы данных;

    • разработка
      приложений;

    • реализация;

    • загрузка
      данных;

    • тестирование;

    • эксплуатация
      и сопровождение

1.Разработка плана базы данных

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

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

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

  • сбор
    сведений;

  • выделение
    объектов;

  • моделирование
    объектов;

  • определение
    типов данных для каждого объекта;

  • определение
    связей между объектами.

Сбор
сведений:

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

Выделение
объектов:

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

Основным
объектом в образце базы данных База
данных AdventureWorks2008R2, поставляемом вместе
с SQL Server, является велосипед. Объектами,
связанными с велосипедом внутри компании,
являются ее сотрудники, производящие
велосипеды, поставщики деталей,
необходимых для производства, клиенты,
покупающие велосипеды, а также
осуществляемые сделки купли-продажи.
Каждому из указанных объектов соответствует
таблица базы данных.

Моделирование
объектов:

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

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

Определение
типов данных для каждого объекта:

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

  • Столбцы
    необработанных данных

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

  • Категориальные
    столбцы

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

  • Столбцы
    идентификаторов

Эти
столбцы предоставляют механизм
идентификации каждого элемента,
хранящегося в таблице. В названиях
подобных столбцов часто присутствуют
строки «ID» и «number», например employee_id,
invoice_number и publisher_id. Столбец идентификатора
является основным компонентом,
используемым для получения доступа к
строкам данных таблицы, как пользователями,
так и внутренними функциями базы данных.
В некоторых случаях идентификатор
объекта может обладать реальным смыслом,
например являться номером социального
страхования. Однако в большинстве
случаев при определении таблицы для
хранения строк данных создается надежный,
искусственный идентификатор.

  • Реляционные
    или ссылочные столбцы

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

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

Введение

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

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

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

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

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

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

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

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

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

1.   Рассмотреть теоретические аспекты и организации БД и СУБД.

2.       Изучить текстовые базы, сетевые и реляционные базы.

.        Рассмотреть проектирование баз данных.

.        Изучить анализ предметной области и запросов к БД.

5.   Изучить построение концептуальной модели, логическое проектирование.

6.   Рассмотреть СУБД Ассеss.

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

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

В первой главе рассматриваются теоретические аспекты СУБД.

Вторая глава рассказывает о проектировании баз данных.

В третьей глав рассматривается СУБД Ассеss.

В заключении подводятся итоги, делаются выводы.

1.  
Теоретические аспекты СУБД

1.1 Некоторые сведения о типах данных

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

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

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

Совокупность простых данных можно объединить в составное данное двумя
способами. Во-первых, можно соединить несколько разнотипных данных. Например,
данное АНКЕТА состоит из данных ТАБЕЛЬНЫЙ НОМЕР, ФИО, ГОД РОЖДЕНИЯ, ПОЛ,
ДОЛЖНОСТЬ, ЗАРПЛАТА. По этому принципу образуется структурное данное или данное
типа структура.

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

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

Элементы массива могут идентифицироваться ключом – данным, значения
которого взаимно однозначно определяют экземпляры элементов [1,44].

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

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

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

                                        
                                   Послужной список

                                                                                                            
Зарплата    

                                                 Дата                           
Работа

ФИО                Пол

Год рождения

                                           
Массив

                                       
Структура

                                          
                 Сотрудники

                                          
Анкета

                                                                             Зарплата

                                                                      
Послужной список

                            
ФИО

                                                 Дата

                            
Дата                                                    Работа

  Число                                                

                                                    
Должность             Организация

                Месяц           Год

Рис.1 – Многоуровневое данное

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

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

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

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

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

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

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

банк данных (БнД) – основанная на технологии БД система программных,
языковых, организационных и технических средств, предназначенных для
централизованного накопления и коллективного использования данных;

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

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

форма
отчет электронный документация

1.2 Текстовые базы данных

Объектами хранения в текстовых БД являются тексты. Под текстом будут
пониматься неструктурированные данные, построенные из строк.

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

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

·  
Деление отраслей
знаний на классы и подклассы проводится по одному основанию;

·  
Подклассы должны
исключать друг друга;

·  
При делении
классов на подклассы должна соблюдаться непрерывность.

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

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

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

Лексическая единица – наименьшая смысловая единица, задаваемая при
построении языка.

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

1.     Отношения вид – род (вышестоящий дескриптор);

2.       Отношения род – вид (нижестоящие дескрипторы);

.        Синонимы;

.        Ассоциативные связи

В тезаурусы помещаются дескрипторы и недескрипторы, хотя существуют
тезаурусы только из дескрипторов [1,69].

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

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

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

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

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

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

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

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

Одним из наиболее эффективных методов представления знаний являются
сетевые модели.

В основе моделей лежит понятие сети, вершинами которой являются понятия,
соответствующие объектам, событиям, процессам, явлениям, а дугами – отношения
между этими понятиями.

Узлы и связи можно наглядно изображать в виде диаграмм.

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

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

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

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

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

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

1.  Вся информация в базе данных представлена в виде таблиц.

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

Реляционная модель обеспечивает независимость данных на двух уровнях –
физическом и логическом. Физическая независимость данных означает с точки
зрения пользователя, что представление данных абсолютно не зависит от способа
их физического хранения. Как следствие этого, физическое перемещение данных
никоим образом не может повлиять на логическую структуру базы данных. Другой
тип независимости, обеспечиваемый реляционными системами – логическая
независимость – означает, что изменение взаимосвязей между таблицами и строками
не влияет на правильное функционирование программных приложений и текущих запросов
[3,124].

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

Виртуальные таблицы можно рассматривать как некоторую перемещаемую по
таблицам рамку, через которую можно увидеть только необходимую часть информации.
Виртуальные таблицы можно получить из одной или нескольких таблиц базы данных (
включая и другие виртуальные таблицы), используя любые операции выбора,
проектирования и объединения. Виртуальные таблицы, в отличие от «настоящих»,
или базовых таблиц, физически не хранятся в базе данных. В то же время
необходимо осознавать, что виртуальные таблицы это не копия некоторых данных,
помещаемая в другую таблицу. Когда вы изменяете данные в виртуальной таблице,
то тем самым изменяете данные в базовых таблицах. В идеальной реляционной
системе с виртуальными таблицами можно оперировать как и с любыми другими
таблицами. В реальном мире на виртуальные таблицы накладываются определенные
ограничения, в частности на обновление. Одно из правил Кодда гласит, что в
истинно реляционной системе над виртуальными таблицами можно выполнять все
«теоретически» возможные операции. Большинство современных систем управления
реляционными базами данных не удовлетворяют этому правилу полностью.

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

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

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

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

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

– Определяться на языке высокого уровня, используемом системой для всех
других целей;

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

Эти возможности в том или ином виде реализованы в большинстве систем.

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

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

Процедуры, выполняемые на
этапах жизненного цикла БД

Проектирование

Создание

Эксплуатация

Анализ предметной области и
запросов к БД

Генерация схемы БД

Реорганизация БД

Организация доступа к базам
данных

Контроль состояния БД

Интеграция пользовательских
представлений

Подготовка среды хранения

Реструктуризация БД

Поиск и обновление данных

Сбор и анализ статистики
использования

Выбор средства реализации

Ввод и контроль данных

Реформатизация БД

Вывод отчетов

Контроль целостности БД

Логическое проектирование

Загрузка и корректировка БД

Разграничение доступа

Физическое проектирование

Инициирование и завершение
работы с СУБД

Рис. 2

.1 Анализ предметной области и запросов к БД

На данном этапе необходимо проанализировать запросы пользователей,
выбрать информационные объекты и их характеристики и на основе анализа
структурировать предметную область (рис. 3).

Анализ предметной области целесообразно разбить на три фазы:

·  
Анализ
концептуальных требований и информационных потребностей;

·  
Выявление
информационных объектов и связей между ними;

·  
Построение
концептуальной модели предметной области и проектирование концептуальной схемы
БД

Объекты реального мира

Ограничения эксплуатации
(технология)

Входные / выходные/
документы

Уровень реальности

Описания объектов
предметной области

Внешние пользовательские
представления (описание функций приложений – задач)

Уровень концептуального
проектирования

Описание предметной области
на языке описания данных выбранной СУБД

Описание входных и выходных
форм документов и функций обработки данных на языках описания входных и
выходных форм запросов выбранной СУБД

                                     
Уровень формальных текстов (логическое проектирование)

        
Описание                                                                      
Уровень физической    Библиотека

           Базы                                                                                  
реализации           входных и  запросов

         
Данных                                                                                                                   
 вых. форм

Рис. 3. Анализ концептуальных требований

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

1.     Анализ требований пользователей к БД (концептуальных требований);

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

.        Выявление перспективных задач (перспективных приложений);

.        Документирование результатов анализа.

Требования пользователей к разрабатываемой БД представляют собой список
запросов с указанием их интенсивности и объемов данных. Эти сведения
разработчики получают в диалоге с будущими пользователями БД. Здесь же
выясняются требования к вводу, обновлению и корректировке информации.
Требования пользователей уточняются и дополняются при анализе имеющихся и
перспективных приложений [6,18].

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

1. Сколько учеников учится в школе?

2. Сколько смен и классов в школе?

3. Как распределены учащиеся по классам
и сменам?

4. Сколько предметов дается по каждой
параллели и в каких объемах?

5. Сколько имеется учебных классов?

6. Сколько преподавателей в школе их
специализация и классность?

7. Как часто обновляется информация в
БД?

8. Какие существуют виды отчетов,
справок и диаграмм?

Необходимо решить задачи:

1. Ведения личных дел учащихся

2. Ведения классных журналов

3. Составление расписания занятий

4. Ведения табеля рабочего времени
преподавателей

На основе информации хранящейся в БД необходимо выдавать следующие
отчеты:

1. Табель успеваемости

2. Ведомость успеваемости и посещаемости
класса

3. Динамика роста успеваемости по
классам и школе

4. Отчет по успеваемости за год

5. Таблица мониторинга учебного процесса

6. Статистические данные по количеству
учащихся

7. Результаты тестирования

8. Результаты работы учителей

9. Результаты выпускных экзаменов

10. Качество знаний учащихся

11. Отчет по предмету

12. Табель по питанию

13. Акт о несчастном случае

14. Протокол экзамена за курс средней
школы

15. Сведения о травматизме за учебный год

16. Сведения подаваемые классным
руководителем за четверть

17. Список выбывших учащихся

18. Движение за год

19. Список оставшихся на второй год

20. График результатов успеваемости по
четвертям

21. График итогов успеваемости по годам

Выявление информационных объектов и связей между ними

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

При выборе информационных объектов необходимо ответить на ряд вопросов:

1. На какие таблицы можно разбить
данные, подлежащие хранению в БД?

3. Какие наиболее интересные
характеристики (с точки зрения пользователя) можно выделить?

4. Какие имена можно присвоить выбранным
характеристикам?

В нашем случае предполагается завести следующие таблицы (рис 4):

Школа

Класс

Предметы

Ученики

Учителя

Оценки

Номер

Класс

Предмет

Класс

Фамилия

Класс

Телефон

Смена

Фамилия

Имя Отчест

Предмет

Директор

Имя

Предмет

Фамилия

Имя

Дата

Оценка

Рис. 4

В ходе этого процесса необходимо ответить на следующие вопросы:

1. Какие типы связей между
информационными объектами?

2. Какое имя можно присвоить каждому
типу связей?

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

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

1. Какова область значений для числовых
характеристик?

2. Каковы функциональные зависимости
между характеристиками одного информационного объекта?

3. Какой тип отображения соответствует
каждому типу связей?

Выделим связи
между информационными объектами (рис.5)

Рис. 5

При проектировании БД существуют взаимосвязи между информационными
объектами трех типов: «один к одному», «один ко многим», «многие ко многим» (рис.6).

Например:

Ученик

Один к одному

Личное дело

Класс

Один ко многим

Ученик

Ученик

Многие к многим

Преподаватель

Рис. 6

.2 Построение концептуальной модели

В простых случаях для построения концептуальной схемы используют
традиционные методы агрегации и обобщения. При агрегации объединяются
информационные объекты (элементы данных) в один в соответствии с семантическими
связями между объектами. Например, урок истории в 10 «а» классе проводится в
кабинете №7, начало в 9-30. Методом агрегации создаем информационный объект
(сущность) РАСПИСАНИЕ со следующими атрибутами: «класс», «предмет», «кабинет»,
«время». При обобщении информационные объекты (элементы данных) объединяются в
родовой объект (рис.7):

Русский язык

Литература

Филология

Иностранные языки

Рис. 7

Выбор модели диктуется прежде всего характером предметной области и
требованиями к БД. Другим немаловажным обстоятельством является независимость
концептуальной модели от СУБД, которая должна быть выбрана после построения
концептуальной схемы [7,77].

Модели «сущность-связь», дающие возможность представлять структуру и
ограничения реального мира, а затем трансформировать их в соответствии с
возможностями промышленных СУБД, являются весьма распространенными.

Под сущностью понимают основное содержание того явления, процесса или
объекта, о котором собирают информацию для БД. В качестве сущности могут
выступать место, вещь, личность, явление и т.д. При этом различают тип сущности
и экземпляр сущности. Под типом сущности обычно понимают набор однородных
объектов, выступающих как целое. Понятие «экземпляр сущности» относится к
конкретному предмету. Например:

Тип сущности – ученик

Экземпляр сущности – Иванов, Петров, Сидоров и др.

В нашем примере Школа, Класс, Предметы, Ученики, Учителя, Оценки –
сущности. Проанализируем связи между сущностями (рис.8).

Название связи

Между сущностями

Учится

Ученик

Класс

Изучает

Ученик

Предмет

Школа

Класс

Преподает

Учитель

Предмет

Работает

Учитель

предмет

Рис. 8

Теперь можно перейти к проектированию информационной (концептуальной)
схемы БД (атрибуты сущностей на диаграмме не показаны) (рис.9).

 принадлежит

Школа

Класс

 Учится

Ученик

работает

       изучает

Учитель

Преподает

Предмет

          экзамен

Ведомость

Рис. 9

2.3Логическое проектирование

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

1. Выбор конкретной СУБД;

2. Отображение концептуальной схемы на
логическую схему;

3. Выбор языка манипулирования данными.

Выбор конкретной СУБД.

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

Конструирование баз данных на основе реляционной модели имеет ряд важных
преимуществ перед другими моделями:

– Независимость логической структуры от физического и пользовательского
представления.

Гибкость структуры базы данных – конструктивные решения не ограничивают
возможности разработчика БД выполнять в будущем самые разнообразные запросы.

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

Отображение концептуальной схемы на логическую схему

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

Выбор языка манипулирования данными

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

1.       Характеристики ПК: тип, модель, фирма производитель, наличие
гарантии.

2.       Управление файлами и поиск: тип связи, модификация нескольких
файлов, двунаправленное соединение таблиц, язык манипулирования данными, тип
поиска.

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

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

.        Отчеты: отчеты по нескольким файлам, сохранение форматов
отчетов, выдача отчета на экран, выдача отчета на магнитный носитель,
вычисляемые поля, группы, переопределение формата даты, заголовки отчетов,
генератор отчетов, итоговые поля, максимальная ширина отчета.

.        Операционная среда: тип операционной системы, объем требуемой
оперативной памяти, необходимость использования постоянной памяти, объем
требуемой постоянной памяти, язык подсистемы.

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

3.     СУБД Access

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

Для работы с СУБД Access 2.0 требуются:

IBM PC или совместимый компьютер с процессором 386 или выше;

DOS 3.3 или выше;

Microsoft Windows 3.1 или выше;

Не менее 6 МВ оперативной памяти (рекомендуется 8 МВ);

20 МВ свободной памяти на жестком диске;

Мышь.

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

Так как Microsoft Access является современным приложением Windows, можно
использовать в работе все возможности DDE (динамический обмен данными) и OLE
(связь и внедрение объектов). DDE позволяет осуществлять обмен данными между
Access и любым другим поддерживающим DDE приложением Windows. В Microsoft
Access можно при помощи макросов или Access Basic осуществлять динамический
обмен данными с другими приложениями [9,23].является более изощренным средством
Windows, которое позволяет установить связь с объектами другого приложения или
внедрить какие-либо объекты в базу данных Access. Такими объектами могут быть
картинки, диаграммы, электронные таблицы или документы из других поддерживающих
OLE приложений Windows.

В Microsoft Access для обработки данных базовых таблиц используется
мощный язык SQL (структурированный язык запросов). Используя SQL можно выделить
из одной или нескольких таблиц необходимую для решения конкретной задачи
информацию. Access значительно упрощает задачу обработки данных. Совсем не
обязательно знать язык SQL. При любой обработке данных из нескольких таблиц
Access использует однажды заданные связи между таблицами.

В Microsoft Access имеется также простое и в то же время богатое
возможностями средство графического задания запроса – так называемый «запрос по
образцу» (query by example), которое используется для задания данных,
необходимых для решения некоторой задачи. Используя для выделения и перемещения
элементов на экране стандартные приемы работы с мышью в Windows и несколько
клавиш на клавиатуре, можно буквально за секунды построить довольно сложный
запрос.Access спроектирован таким образом, что он может быть использован как в
качестве самостоятельной СУБД на отдельной рабочей станции, так и в сети – в
режиме «клиент-сервер». Поскольку в Microsoft Access к данным могут иметь
доступ одновременно несколько пользователей, в нем предусмотрены надежные
средства защиты и обеспечения целостности данных. Можно заранее указать, какие
пользователи или группы пользователей могут иметь доступ к объектам (таблицам,
формам, запросам) базы данных. Microsoft Access автоматически обеспечивает
защиту данных от одновременной их корректировки разными пользователями. Access
также опознает и учитывает защитные средства других подсоединенных к базе
данных структур (таких, как базы данных Paradox, dBASE и SQL).

Практически все существующие СУБД имеют средства разработки приложений,
которые могут использованы программистами или квалифицированными пользователями
при создании процедур для автоматизации управления и обработки данных.Access
предоставляет дополнительные средства разработки приложений, которые могут
работать не только с собственными форматами данных, но и с форматами других
наиболее распространенных СУБД. Возможно, наиболее сильной стороной Access
является его способность обрабатывать данные электронных таблиц, текстовых
файлов, файлов dBASE, Paradox, Btrieve, FoxPro и любой другой базы данных SQL,
поддерживающей стандарт ODBE. Это означает, что можно использовать Access для
создания такого приложения Windows, которое может обрабатывать данные,
поступающие с сетевого сервера SQL или базы данных SQL на главной ЭВМ.

Все выше сказанное позволило остановить выбор на СУБД Access для
постановки и решения задачи автоматизации процесса ведения документации и
отчетности в учебном заведении.

Таблицы.

Работа в Access начинается с определения реляционных таблиц и их полей,
которые будут содержать данные. Далее определяются реляционные связи между
таблицами. Так как данная тема не входит в дипломную работу, то опустим процесс
их создания. Конечным результатом данного этапа является таблица реляционных
связей, приведенная на рисунке 10.

Рис. 10

Формы.

Рис. 11

Формы – одно из основных средств для работы с базами данных в Access –
используются для ввода новых записей (строк таблиц), просмотра и редактирования
уже имеющихся данных, задания параметров запросов и вывода ответов на них и др.
Формы представляют собой прямоугольные окна с размещенными в них элементами
управления.

Существует возможность создания форм динамически при исполнении
программы, однако естественным режимом их создания является режим визуального
конструирования (рис.11). Выбор команды Форма в меню Вставка выводит на экран
окно Новая Форма, позволяющее задать таблицу или запрос, для которых создается
новая форма, и указать режим ее создания. Кроме создания формы «вручную»,
создание формы можно автоматизировать, используя Мастер форм (FormWizard).
Кроме того, можно создать специальные формы, в том числе с листами данных
(Autoform: Datasheet), диаграммами (Chart Wizard) и сводными таблицами
(PivotTable Wizard) в формате Excel.

Рис. 12

В большинстве случаев для создания элемента управления достаточно
перетащить его на форму из панели инструментов. Каждый элемент помещается в
определенный раздел формы. В зависимости от типа раздела (Заголовок формы,
Область данных и др.) элемент управления будет появляться однажды, отображаться
на каждой странице, в каждой группе записей или для каждой записи [12,36].

Для создания
формы с помощью Мастера форм (FormWizard) предполагается следующая
последовательность действий:

Выберите Формы / Создать. На экране появится окно диалога «Новая форма»,
в котором необходимо выбрать метод построения формы и исходный объект для
построения формы. В качестве такого объекта могут быть выбраны таблица или
запрос (рис.13).

Рис.13

Допустим в качестве исходной таблицы мы выбрали Оборудование, в качестве
метода создания форм – Мастер форм. После нажатия кнопки Ok, переходим к
следующему диалоговому окну (рис. 14).

Рис. 14

Рис. 15

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

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

На последнем шаге можно изменить предлагаемое Мастером название формы на
свое собственное и на этом завершить процесс создания формы нажав кнопку
Готово.

Если по каким-либо причинам форма вас не удовлетворяет, нажмите кнопку
Конструктор, и вы перейдете в режим конструктора форм, в котором получите в
свое распоряжение все средства для создания полноценной формы.

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

Рис.16

Пусть, например, мы создаем отчет с помощью Мастера для распечатки списка
всех учеников класса. В качестве исходных данных выберем запрос Класс_ФИО,
который содержит поля Класс и Фамилия.

На следующем шаге Мастер отчетов предлагает осуществить группировку
данных. Так Класс будет печататься только один раз в заголовке листа, а фамилии
учеников – в виде списка в одну колонку (рис 17).

Рис. 17

После чего Мастер отчетов предлагает ввести сортировку. Допускается
сортировка записей в возрастающем или убывающем порядке, включающая до четырех
полей (рис 18).

Рис. 18

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

Рис.19

Шагнув далее, вы увидите на экране окно диалога с клетчатым флагом,
который указывает на то, вы подошли к финишу.

Задайте наименование отчета и нажмите кнопку Готово (рис. 20).

Рис. 20

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

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

Вопросы объекно ориентированного программирования выходят за рамки данной
дипломной работы.

Заключение

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

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

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

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

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

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

Список использованных источников

1. Биллиг В.А., Дехтярь М.И., VBA и Office 97 Офисное программирование, М., изд. «Русская
редакция», 1999

2. Бемер С, Фратер Г., MS Access … для пользователя, Киев, «BHV», 1994, М., «Бином», 1999

3. Винтер Рик, Microsoft Access 97, Справочник, С.-Пб., «Питер», 1999

4. Вейскас Д., Эффективная работа с Microsoft Access 2, С.-Пб.,1999

5. Гусева Т.И., Башин Ю.Б. ,
Проектирование баз данных в примерах и задачах, М.,1999

6. ГОСТ 2716-86 «Дисплей ЭВМ на
электронно-лучевых трубках»

7. «Методические рекомендации по
профилактике переутомления при работе с видеотерминалами», М., Инс-т гигиены
им. Ф.Ф. Эрисмана, 1999

8. Росс Нельсон
,Running Visual Basic for Windows, М., изд. «Русская редакция», 1999

9. Сан. П и Н 2.22.542-99 «Гигиенические
требования к ВДТ и ПЭВМ.

10. Санитарные правила и нормы»

11. СН иП 23-05-99 «Естественное и
искусственное освещение»

12. Савельев В.А., Персональный компьютер
для всех (кн.3), Создание и использование баз данных, М.,2001

13. Тимоти Бадд, Объектно-
ориентированное программирование в действии, С.-Пб., 1999

14. Хоффбауэр М., Шпильманн К., ACCESS 7.0, Сотни полезных рецептов, Киев,
«BHV», 1999

15. Хомоненко А.Д. Базы данных . – Спб.:
Корона – принт,2000.