ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 21.06.2021
Просмотров: 292
Скачиваний: 1
1
Тема 3
Базы данных. Классификация баз данных. Основные понятия баз данных.
План лекции
1.
Базы данных. Основные понятия баз данных. Классификация баз данных.
2.
Этапы проектирования баз данных. Понятие концептуальной, логической, физической
моделей.
3.
Принципы построения баз данных.
4.
Жизненный цикл баз данных.
5.
Язык SQL, назначение, основные команды языка.
1.Базы данных. Основные понятия баз данных.
Обработка больших объемов информации становится не под силу человеку, поэтому для
быстрой и достоверной обработки данных используются персональные компьютеры. Информация в
компьютере структурируется и хранится, как правило, в виде таблиц. В свою очередь, отдельные
таблицы объединяются в базы данных.
Базы данных (БД)
— это один или несколько файлов данных, предназначенных для хранения,
изменения и обработки больших объемов взаимосвязанной информации. Примерами баз данных могут
быть телефонная книга, каталог товаров, штатное расписание и т. д.
Мало создать базу данных, надо разработать механизмы извлечения информации из базы данных
и способы ее представления на экране и бумаге. Для этих целей предназначена система управления
базами данных (СУБД).
СУБД
— это система программного обеспечения, предоставляющая доступ к данным многих
пользователей. СУБД обеспечивает правильность, полноту и непротиворечивость данных, а также
простой и понятный интерфейс.
Основой баз данных является информация (данные) о конкретной группе предметов (объектов).
Объект —
это нечто существующее и различимое, обладающее набором свойств.
Отличие одного объекта от другого определяется конкретными значениями свойств. Объекты
бывают материальные и идеальные. К материальным объектам относятся предметы материального
мира: автомобиль, здания, предметы мебели и т. д. К идеальным (абстрактным) объектам можно
отнести спектакль, содержание книги и т. д.
Сущность —
отображение объекта в памяти человека или компьютера.
Параметр
— конкретное значение любого из свойств объекта.
Атрибут —
конкретное значение любого из свойств сущности.
Таблица —
некоторая регулярная структура, состоящая из конечного числа записей (строк). Как
правило, в базах данных используются двумерные массивы (матрицы).
Запись —
это одна строка таблицы (или нескольких таблиц), полностью описывающая одну
сущность. Каждая запись состоит из конечного числа полей.
Поле
— это один элемент записи, в котором хранится конкретное значение атрибута.
Первичный ключ —
это атрибут или группа атрибутов, которые однозначно определяют каждую
запись в таблице. Первичный ключ всегда должен быть уникальным, то есть его значения не должны
повторяться.
Связь —
это функциональная зависимость между сущностями. Если между некоторыми
сущностями существует связь, то атрибуты из одной сущности ссылаются или некоторым образом
связаны с атрибутами другой сущности.
Хранимая процедура —
это приложение (программа), объединяющая запросы пользователя и
процедурную логику и хранящаяся в базе данных.
Правило —
это логическое условие, определяющее значение одного атрибута в зависимости от
значения другого атрибута (или группы атрибутов). С помощью правила контролируется достоверность
вводимой информации.
Ограничение —
это логическое условие, накладывающее ограничение (интервал допустимых
значений) на значение атрибута.
2
Триггер —
это предварительно определенное действие или последовательность действий,
автоматически осуществляемых при выполнении операций обновления, добавления или удаления
данных. Триггер выполняется автоматически при выполнении указанных действий и не может быть
отключен. Триггер включает в себя:
правила или ограничения;
событие, которое требует проверки правил и ограничений;
предусмотренные действия, которые выполняются с помощью процедуры или
последовательности процедур.***
Ссылочная целостность —
это обеспечение непротиворечивости функциональных взаимосвязей
между сущностями. Непротиворечивость выполняется путем соответствия значений первичного ключа
родительской сущности значениям внешнего (любого не первичного) ключа дочерней сущности.
Ссылочная целостность может контролироваться при всех операциях, изменяющих информацию в базе
данных, при этом возможны следующие варианты обработки событий:
отсутствие проверки;
проверка допустимости;
запрет операции;
каскадное выполнение операций обновления или удаления данных
одновременно в нескольких связанных таблицах;
установка пустого значения по умолчанию.
Нормализация отношений
— это процесс построения оптимальной структуры таблиц и связей в
реляционной БД. В процессе нормализации данные группируются в таблицы, представляющие объекты
и их взаимосвязи.
Словарь данных
— это централизованное хранилище сведений о сущностях, взаимосвязях между
сущностями, их источниках, значениях, использовании и форматах представления.
Классификация баз данных:
По характеру хранимой информации:
— Фактографические (картотеки),
— Документальные (архивы)
По способу хранения данных:
— Централизованные (хранятся на одном компьютере),
— Распределенные (используются в локальных и глобальных компьютерных сетях).
По структуре организации данных:
— Табличные (реляционные),
— Иерархические.
2. Этапы проектирования баз данных. Понятие концептуальной, логической, физической
моделей.
Этапы проектирования баз данных
1 Построение информационной модели и определение сущностей
На этом этапе проектирования базы данных решаются следующие вопросы:
ставится задача на проектирование базы данных, то есть доказывается актуальность
создания базы данных;
собираются концептуальные требования и, на их основе, строится концептуальная модель
данных.
Концептуальная модель данных составляется по результатам анализа поставленной заказчиком
задачи и обработки концептуальных требований конечных пользователей. Результатом выполнения
первого этапа проектирования является информационная модель данных и список основных сущностей
— прообраз будущих таблиц. В данном случае под сущностью понимается структурное подразделение
фирмы. Концептуальная модель данных будет состоять из совокупности групп концептуальных
требований для каждого структурного подразделения фирмы, причем некоторые концептуальные требо-
вания могут повторяться в разных группах.
3
2 Определение взаимосвязей между сущностями
На этом этапе проектирования определяются направление движения потоков информации между
структурными подразделениями фирмы-заказчика базы данных, источники возникновения
информации, места ее модификации и потребления. Результатом выполнения этого этапа
проектирования будет функциональная схема движения потоков информации, с указанием типов
взаимосвязей, между структурными подразделениями фирмы. Логическая модель описывает понятия
предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной
областью. Логическая модель данных является начальным прототипом будущей базы данных.
Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД.
Более того, логическая модель данных необязательно должна быть выражена средствами именно
реляционной модели данных. Основным средством разработки логической модели данных в настоящий
момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).
3 Задание первичных и альтернативных ключей
Для каждой структурной единицы фирмы определяются атрибуты (данные), которые будут
храниться в базе данных, а также первичный и альтернативный ключи. Добавление ключей в список
концептуальных требований необходимо для обеспечения организации движения потоков информации
между структурными подразделениями фирмы, в соответствии со вторым этапом проектирования базы
данных. Кроме того, при анализе концептуальных требований определяется, какие алгоритмы и расчеты
исходных величин (хранимые процедуры) будут храниться вместе с базой данных. При этом количество
хранимых процедур должно быть минимальным.
4 Приведение модели к требуемому уровню нормальной формы
На этом этапе проектирования выполняется главная задача — нормализация отношений. В
процессе нормализации концептуальные требования группируются в таблицы. На этом этапе про-
ектирования концептуальные требования для каждого структурного подразделения могут быть сведены
либо в одну таблицу, либо в несколько таблиц. Здесь также решается вопрос ликвидации избыточной
информации, то есть концептуальные требования, используемые несколькими структурными
подразделениями, сводятся в одну таблицу с одновременным добавлением ключей для перехода в
другие таблицы (для других структурных подразделений). Таким образом, добиваются существенного
сокращения объема памяти. На этом этапе также решается вопрос о том, какие таблицы будут
справочниками, то есть информация в этих таблицах не изменяется или изменяется очень медленно.
Следует иметь в виду, что чрезмерное увеличение количества таблиц приводит к потере общей идеи
создания базы данных, и сама база данных становится трудной для понимания и управления. Для базы
данных объема предприятия оптимальное количество таблиц должно быть не более сорока или
пятидесяти.
После выполнения четвертого этапа проектирования должна быть получена структура базы
данных: количество таблиц, список атрибутов (концептуальных требований), которые хранятся в
каждой таблице, первичные и внешние ключи для перехода между таблицами, виды взаимосвязей
между таблицами и список хранимых процедур.
5 Физическое описание модели
На этом этапе каждая таблица, созданная на четвертом этапе:
получает свое имя, под которым она будет храниться в базе данных;
каждый атрибут (концептуальное требование) таблицы получает свое
имя, тип и размер;
для каждого ключа, как первичного, так и внешнего, определяются
его характеристики
На пятом этапе также предусматриваются меры по обеспечению ссылочной целостности, то есть
установление между таблицами не противоречивых взаимосвязей. Установление не противоречивых
взаимосвязей и обеспечение достоверности в данных в любой момент времени является главной и
самой трудоемкой
задачей.
4
В результате выполнения работ по пятому этапу можно определить технические характеристики
персонального компьютера: объем оперативной памяти, объем памяти на жестком диске и т.д.
3.Принципы построения баз данных.
Проектирование баз данных начинается со сбора концептуальных требований. Концептуальное
требование — это одно данное (одно свойство объекта), которое будет храниться в базе данных.
Концептуальные требования получают как от руководства фирмы, так и в основном от конечных
пользователей, то есть от сотрудников, непосредственно работающих с базой данных. Кроме того, на
этом этапе решается вопрос — какие действия по обработке данных должны выполняться в базе
данных. База данных должна:
удовлетворять требованиям заказчика и содержать сведения только о тех объектах, которые
интересуют заказчика;
обладать приемлемым быстродействием, то есть пользователь должен получать
необходимые ему сведения за короткое время;
иметь возможность последующего расширения без существенной переделки, как самой
базы данных, так и средств управления ею;
не зависеть (или мало зависеть) от количества помещаемых в нее данных;
легко перестраиваться при изменении программной и аппаратной среды;
содержать только достоверные данные. Достоверность данных должна обеспечиваться
как при вводе новых данных, так и при редактировании уже имеющихся данных;
– доступ к данным должны иметь определенные лица.
Поскольку база данных является основным компонентом автоматизированной информационной
системы, её жизненный цикл непрерывно связан с жизненным циклом АИС, с жизненным циклом
программного обеспечения АИС. Жизненный цикл АИС, в целом, определяется как период времени,
который начинается с момента принятия решений о необходимости создания АИС и заканчивается
завершением её полной эксплуатации.
4.Жизненный цикл баз данных.
Рассмотрим некоторые этапы жизненного цикла БД.
1 Планирование разработки БД.
Это подготовительные действия, позволяющие с максимально
возможной эффективностью реализовать этапы жизненного цикла БД. На данном этапе решают
следующие задачи:
— анализ функционирования автоматизируемого предприятия в соответствии с требованиями,
предъявляемыми ему — определение бизнес—планов и целей предприятия с последующим выделением
потребностей предприятия в информационных технологиях;
— анализ существующих на предприятии автоматизированных информационных систем с целью
выявления их сильных и слабых сторон (однопользовательские системы, устаревшее программное
обеспечение и т.п.);
— формулирование потребностей в новой АИС (определение всех недостатков существующих
на рынке программного обеспечения подобных АИС, их высокая стоимость, высокая сложность их
сопровождения и т.п.);
— разработка стандартов, определяющих технологию сбора данных, их форматов, определение
состава требуемой технической документации, порядка проектирования и реализации.
2 Определение требований к системе.
Это этап определения диапазона действия и границ
разрабатываемой БД, состава её пользователей, областей применения.
Задачи этапа:
— анализ и выбор направления совершенствования объекта управления в рамках предприятия;
— установление границ исследуемой области;
— связь разрабатываемой системы с существующими на предприятии АИС;
— выбор программно—технических средств;
— определение ограничения ресурсов на разработку;
— определение состава возможных будущих пользователей;
— определение направлений развития.
5
3
Сбор и анализ требований пользователей
. Сбор и анализ информации о той части
предприятия, работа которого будет поддерживаться с помощью создаваемой АИС. Необходимая для
проектирования БД информация может быть собрана следующими способами:
— посредством опроса специалистов предприятия в наиболее важных областях его
деятельности;
— с помощью наблюдения за деятельностью предприятия;
— посредством изучения документов, особенно тех, которые используются для сбора или
представления информации – входных, выходных документов;
— за счет использования опыта проектирования других подобных систем;
— с помощью анкет. Например, проведение анкетного опроса руководителей подразделений,
будущих пользователей БД. В связи с разным функциональным назначением подразделений, у
руководителей может быть разное видение предметной области.
На этапе сбора и анализа требований пользователей полезно ответить на следующие вопросы:
а) Что лежит в основе деятельности данного предприятия. Выявляются наиболее важные
компоненты, подлежащие автоматизации. Например: подсистема «Управление персоналом» –
компоненты: предприятие, отделы, организационно—кадровая структура, личная карта сотрудника,
приказ; задача «Почта» – компоненты: отправитель, получатель, почтовое отделение, главпочта;
задача «Занятость населения» – компоненты: отдел по трудоустройству, предприятия, учебные
заведения, начисление пособий; задача «Учет кассовых операций» – компоненты: касса, бухгалтерия.
б) Как это делается? Определяется список основных процессов, происходящих на данном
предприятии, в частности над компонентами. Например, задача «Почта» – обеспечивается ввод,
хранение и обработка данных об отправителе, получателе и почтовом отделении. Автоматически
рассчитывается сумма оплаты почтовых услуг и выдается квитанция об оплате. Каждый день
составляются и выдаются на печать отчеты о принятых и выданных почтовых отправлениях; задача
«Занятость населения» – сбор, накопление, обработка и передача данных о безработных, регистрация
вакантных рабочих мест, заполнение карточек персонального учета, ведение истории по безработице,
выдача рекомендательных писем; задача «Учет кассовых операций» – ведение журнала регистрации
кассовых операций, оформление приходных и расходных, кассовых ордеров и т.п.
в) Где происходят данные процессы? Территориально определяется положение компонентов,
решается вопрос оптимального распределения данных (локальная, сетевая БД, БД уровня предприятия,
распределенные БД).
г) Кто выполняет эти процессы? Рассматривается организационная структура предприятия –
подчинение и зависимость подразделений.
д) Когда выполняется то или иное действие? Проясняется периодичность времени
осуществляемых процессов, последовательность выполнения.
е) Почему эти действия выполняются? Определяется мотивация деятельности предприятия.
Например: достижение наилучших соотношений "затраты – удобства" для клиентов; обеспечение
успешной деятельности персонала; получение приемлемой прибыли; повышение доходов при
автоматической обработке данных; получение более эффективного управления.
В результате полученных ответов на данные вопросы должны быть сформированы и
утверждены, как минимум, следующие документы, на основе которых будет производиться
проектирование программной системы:
— название задачи;
— организационная структура предприятия;
— описание существующих на предприятии информационных потоков, выделение
автоматизируемых;
— описание структуры входных и выходных документов;
— функции, которые должны быть автоматизированы в рамках данной задачи;
— формализованное описание предметной области – классы объектов (сущности) и связи
между ними;
— правила (бизнес – правила, семантические утверждения), ограничивающие предметную
область;
— требования к программному обеспечению АИС;
— требования к техническому обеспечению АИС;
— сроки ввода в эксплуатацию АИС.