|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Функциональные возможности СУБД
По степени универсальности различают два класса СУБД: · системы общего назначения – реализованные как программный продукт, способный функционировать на ЭВМ в определённой операционной системе и поставляемый пользователям как коммерческое изделие; СУБД общего назначения – это сложные программные комплексы, предназначенные для выполнения всей совокупности функций, связанных с созданием и эксплуатацией БД информационной системы. · специализированные системы – создаваемые в случаях невозможности или не целесообразности использования СУБД общего назначения. Продукты, функционирующие в среде Windows, имеют удобный пользовательский интерфейс и встроенные средства повышения производительности. Рынок программного обеспечения ПК располагает большим числом разнообразных по своим функциональным возможностям коммерческих систем СУБД общего назначения. В рассматриваемую группу программных продуктов вошли: СУБД – лидеры на рынке программ: dBASE IV, компании Borland International; Microsoft Access 97; Microsoft FoxPro 2.6 for DOS; Microsoft FoxPro for Windows, Microsoft Corp: Paradox for DOS 4.5: Paradox for Windows, версия 4.5 Borland.. Производительность СУБД оценивается: · временем выполнения запросов; · скоростью поиска информации; · временем выполнения операций импортирования данных их других форматов; · скоростью выполнения таких операций как обновления, вставка, удаление данных; · максимальным числом параллельных обращений к данным в многопользовательском режиме; · временем генерации отчёта. На производительность СУБД оказывают влияния 2 фактора: - СУБД, которые следят за соблюдением целостности данных, несут дополнительную нагрузку, которую не испытывают другие программы; Производительность собственных прикладных программ сильно зависит от правильного проектирования и построения БД. Целостность данных подразумевает наличие средств, позволяющих удостовериться, что информация в БД всегда остаётся корректной и полной. Операции, обеспечивающие безопасность: · шифрование прикладных программ; · шифрование данных; · защита паролем; · ограничение уровня доступа Хороший уровень безопасности в СУБД dBase IV, Access Для сохранения информации используется двойной подход. Некоторые операции сохранения происходят в обход операционной системы Целостность должна обеспечиваться независимо от того, каким образом данные заносятся в память, не конкретных действий пользователей, пробоев сети и т.п. Он предусматривает назначение паролей для индивидуальных пользователей или групп пользователей и присвоение различных прав доступа отдельно таблицам, запросам, отчётам на уровне пользователя или группы. Основные этапы разработки приложения. Этап 1. Уточнение задач На первом этапе составляется список всех основных задач, которые в принципе должны решаться этим приложением, – включая и те, которые не нужны сегодня, но могут появиться в будущем. Под «основными» задачами понимаются функции, которые должны быть представлены в формах или отчетах приложения. Этап 2. Последовательность выполнения задач Для того, чтобы приложение работало логично и удобно, лучше всего объединить основные задачи в тематические группы и затем упорядочить задачи каждой группы так, чтобы они располагались в порядке их выполнения. Может получиться так, что некоторые задачи будут связаны с разными группами или, что выполнение некоторой задачи должно предшествовать выполнению другой, принадлежащей к иной группе. Этап 3. Анализ данных После формирования списка задач, наиболее важным этапом является составление подробного перечня всех данных, необходимых для решения каждой задачи. Некоторые данные понадобятся в качестве исходных и меняться не будут. Другие данные будут проверяться и изменяться в ходе выполнения задачи. Некоторые элементы данных могут быть удалены или добавлены. И наконец, некоторые данные будут получены с помощью вычислений: их вывод будет частью задачи, но в базу данных вноситься они не будут. Этап 4. Определение структуры данных После предварительного анализа всех необходимых элементов данных нужно упорядочить их по объектам и соотнести объекты с таблицами и запросами базы данных. Для реляционных баз данных типа Access используется процесс, называемый нормализацией, в результате которого вырабатывается наиболее эффективный и гибкий способ хранения данных. Этап 5. Разработка макета приложения и пользовательского интерфейса После задания структуры таблиц приложения, в Microsoft Access легко создать его макет с помощью форм и связать их между собой, используя несложные макросы или процедуры обработки событий. Предварительный рабочий макет легко продемонстрировать заказчику и получить его одобрение еще до детальной реализации задач приложения. Этап 6. Создание приложения В случае очень простых задач созданный макет является практически законченным приложением. Однако довольно часто приходится писать процедуры, позволяющие полностью автоматизировать решение всех намеченных в проекте задач. Поэтому, понадобится создать специальные связующие формы, которые обеспечивают переход от одной задачи к другой. Этап 7. Тестирование и усовершенствование После завершения работ по отдельным компонентам приложения необходимо проверить функционирование приложения в каждом из возможных режимов. Необходимо проверить работу макросов, использовав пошаговый режим отладки, при котором будет выполняться одна конкретная макрокоманда. При использовании Visual Basic для приложений в вашем распоряжении имеются разнообразные средства отладки, позволяющие проверить работу приложения, выявить и исправить ошибки. По мере разработки автономных разделов приложения желательно передать их заказчику для проверки их функционирования и получения мнения о необходимости внесения тех или иных изменений. После того как заказчик ознакомится с работой приложения, у него практически всегда возникают дополнительные предложения по усовершенствованию, какой бы тщательной не была предварительная проработка проекта. Пользователи часто обнаруживают, что некоторые моменты, о которых в процессе постановки задач они говорили как об очень важных и необходимых, на самом деле не играют существенной роли при практическом использовании приложения. Выявление необходимых изменений на ранних стадиях разработки приложения позволяет существенно сократить время на последующие переделки.
Лекция 4 База данных – совокупность данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования данными, которые относятся к определенной предметной области. Под данными понимается информация, представленная в виде, пригодном для обработки автоматическими средствами при возможном участии человека. Давайте остановимся на вопросе классификации баз данных: Разделяются по технологии обработки (об этом мы с вами говорили на прошлой лекции их две централизованная и распределенная) и по способу установления связей между данными. Остановимся немножко подробнее на этом вопросе. По способу установления связей между данными различаются три модели реляционная, иерархическая и сетевая. Реляционная модель данных Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. (русский перевод статьи, в которой она впервые описана опубликован в журнале " СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД. Структура данных. В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф.Кодда утверждается, что " реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название " реляционная" происходит от английского relation - " отношение" ). Перейдем к рассмотрению структурной части реляционной модели данных. Прежде всего необходимо дать несколько определений. Определения:
Пример: если даны два множества A (a1, a2, a3) и B (b1, b2), их декартово произведение будет иметь вид С=A*B (a1*b1, a2*b1, a3*b1, a1*b2, a2*b2, a3*b2)
Пример: на множестве С из предыдущего примера могут быть определены отношения R1 (a1*b1, a3*b2) или R2 (a1*b1, a2*b1, a1*b2)
В основе реляционной модели данных лежит понятие отношения. Неформализованное отношение представляется в виде двухмерной таблицы, на которую накладываются определенные ограничения. Столбец таблицы соответствует понятию атрибута отношения, строка понятию кортежа отношения. Множество различных значений, которые могут появляться в столбце таблицы, понятию домена, на котором определен соответствующий атрибут.
Рис.1 Основные компоненты реляционного отношения. Аналогично можно установить соответствие и с понятием, используемым при определении файлов линейной структуры: отношение – файл; атрибут данное; кортеж – запись файла; домен – множество возможных значений данного. Формальное определение основных понятий реляционной модели данных базируется на теории множеств. Отношение с одной стороны представляется («горизонтали») как множество атрибутов, а с другой - (по «вертикали») – как множество кортежей. Каждому элементу множества атрибутов ставится в соответствие множество значений – домен. По существу отношение соответствует линейной структуре, с соблюдением всех присущих ей требований (один тот же порядок следования атрибутов, один и тот же размер и тип значений одного атрибута во всех кортежах отношений, понятие ключа). Так приведенные на рисунках 1 и 2 структуры СТУДЕНТ и СЕМЕСТР в реляционной модели данных будут отношениями, данные – код студента, Ф.И.О., пол, дата рождения и семестр, оценка рейтинг по дисциплине – атрибутами отношений, а схемой отношения СТУДЕНТ запись вида СТУДЕНТ (код студента, Ф.И.О., пол, дата рождения). В реляционной модели данных акцентируется понятие функциональной зависимости не ключевых атрибутов отношения от ключа в том смысле, что если известен ключ, то не ключевые атрибуты имеют вполне определенное, единственное значение. Обязательное наличие ключа приводит к важному свойству – в отношении не может быть двух одинаковых кортежей. Кроме отмеченных ограничений вводится требование нормализации отношений. Теория реляционной модели данных различает пять нормальных форм, однако для практических целей достаточно соблюдать первые три формы. Нормализация отношений Требование нормализации отношений направлено на обеспечение такой их структуры, которая исключает некорректное обновление значений некоторых атрибутов и ошибки в выполнении определенных операций выборки. Первая нормальная форма Отношение удовлетворяет первой нормальной форме ( 1НФ ), если все его атрибуты атомарны (неделимы), т.е среди атрибутов нет составных или множественных значений. Например, приведенное на рисунке 1 отношение студент не удовлетворяет первой нормальной форме, т.к имеет атрибут место рождения, состоящий из атрибутов республика, область, город (село), а также атрибут иностранный язык (которым владеет студент) с множественными значениями для некоторых студентов. СТУДЕНТ
Рисунок 1 Отношение, не удовлетворяющее первой нормальной форме
Когда говорится о невозможности иметь составной атрибут (например, место рождения) имеется в виду, что невозможно одновременно иметь (обращаться к ним) атрибуты, республика, область, город и те же самые значения именовать как место рождения. Необходимо принять либо первый (детальные атрибуты), либо второй вариант. Если все же необходимо кроме место рождения иметь возможность обращаться к атрибуту город, то необходимо ввести дополнительный атрибут город, где родился. Более значительная специфика связана с атрибутом с множественными значениями. Соблюдая требования одного размера атрибута во всех кортежах, мы должны бы были представить исходное отношение либо в виде рисунка 2 либо в виде рисунка 3. В первом случае размер атрибута иностранный язык, рассчитанный под максимальное возможное число языков, будет неоправданно большим, к тому же процедура поиска кортежей с заданным значением языка будет отличаться от аналогичной процедуры для атрибутов с атомарными значениями.
Рисунок 2 – Размещение множественных значений атрибутов в одном кортеже
Рисунок 3 Организация хранения атрибутов с множественными значениями в виде типичной для реляционной модели однородной структуры. Второе представление снимает предыдущие проблемы, однако, порождает новые, связанные с дублированием значений первых атрибутов для студентов, владеющих несколькими языками. Кроме излишнего расхода памяти здесь возникают проблемы обновления значений (должна быть специальная процедура) и проблема обработки, например подсчет числа объектов, родившихся в некоторый день или диапазоне дат. Реляционная модель требует нормализации (приведения к 1НФ ) путем разбиения исходного отношения на два следующим образом: из исходного отношения СТУДЕНТ исключается атрибут с множественным значением и получается новое отношение СТУДЕНТ 1, а исключенный атрибут вместе с ключом исходного отношения образует новое отношение СТУДЕНТ 2 (рисунок 4) причем оба атрибута являются ключевым). СТУДЕНТ 1
СТУДЕНТ 2
Рисунок 4 – Результат нормализации отношения СТУДЕНТ. Вторая нормальная форма Отношение удовлетворяет второй нормальной форме ( 2НФ ), если оно удовлетворяет 1НФ и не содержит атрибутов, зависящих от части ключа. На рисунке 5 приведено отношение СЕМЕСТР, не удовлетворяющее 2НФ по следующей причине. Ключ отношения составляют атрибуты код студента и номер семестра, т.к. комбинация значений именно атрибутов уникальна для любого кортежа отношения. Вместе с тем, если атрибуты тип стипендии в семестре и рейтинг в семестре, зависят от полного ключа, то Ф.И.О. и дата рождения являются характеристиками студента вне зависимости от семестра, т.е. зависят от части ключа – от атрибута код студента. Схема структуры СТУДЕНТ 3
Рисунок 5 Отношение, не удовлетворяющее второй нормальной форме.
Студент может изменить фамилию и тогда это можно было связать это с семестром, хотя практического смысла в этом нет. При использовании такого ненормализованного отношения возникают проблемы обновления и подсчета числа объектов, отмеченных при рассмотрении примера нормализации по 1НФ. Приведение отношения ко 2НФ и заключается в разбиении исходного отношения на два, одно из которых включает атрибуты ключа исходного отношения и атрибуты, зависящие от полного ключа, а второе – атрибуты зависящего от части ключа вместе с атрибутами этой части. Результат нормализации исходного отношения СТУДЕНТ 3 приведен на рисунке 6. СТУДЕНТ 4
СТУДЕНТ 5
Рисунок 6 – Результат нормализации отношения СЕМЕСТР
Третья нормальная форма Отношение удовлетворяет третей нормальной форме ( 3НФ ), если оно удовлетворяет 2НФ, и среди его не ключевых атрибутов нет зависящих от другого не ключевого атрибута (нет атрибутов, транзитивно зависящих от ключа). На рисунке 7 приведено отношение, не удовлетворяющее 3НФ. СТУДЕНТ 6
Рисунок 7 Отношение, не удовлетворяющее третьей нормальной форме В этом примере ключ состоит из одного атрибута код студента, атрибут Ф.И.О. коменданта общежития однозначно связан с не ключевым атрибутом адрес общежития, где проживает студент, т.е. функционально зависит от него (точно также как и от ключа). Естественно, одно и тоже значение атрибута Ф.И.О. коменданта общежития будет повторяться во всех кортежах, относящихся к студентам, проживающим в одном и том же общежитии. При использовании такого ненормализованного отношения также возникают проблемы корректного обновления (изменения фамилии коменданта) и выборки кортежей. Приведение отношения к 3НФ заключается в разбиении исходного отношения на два (рисунок 8), одно из которых есть исходное отношение без атрибутов, зависящих от не ключевого атрибута. Второе отношение состоит из атрибута, от которого в исходном отношении зависели исключенные атрибуты (оно станет ключом в новом отношении) плюс атрибуты, исключенные из исходного отношения. СТУДЕНТ 7
СТУДЕНТ 8
Рисунок 8 – Результат нормализации отношения СТУДЕНТ Разобравшись с нормальными формами, перейдем к разбору отношений. Именованное множество пар " имя атрибута - имя домена" называется схемой отношения. Мощность этого множества - называют степенью или " арностью" отношения. Набор именованных схем отношений, представляет из себя схему базы данных. Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Понятие первичного ключа — это такой набор атрибутов, который однозначно определяет кортеж и минимален среди всех своих подмножеств (то есть нельзя убрать ни один из атрибутов). При добавлении новых записей первичный ключ обязан оставаться первичным ключом (например, неверным будет использование в качестве первичного ключа набора Имя + Отчество + Фамилия сотрудника, даже если на момент создания таблицы полных тёзок среди заносимых в неё людей не было). В теории реляционных баз данных таблица представляет собой изначально неупорядоченный набор записей. Единственный способ идентифицировать определённую запись в этой таблице — это указать набор значений одного или нескольких полей, который был бы уникальным для этой записи. Отсюда и происходит понятие первичного ключа — набора полей (атрибутов, столбцов) таблицы, совокупность значений которых определена для любой записи (строки) этой таблицы и различна для любых двух записей. Использование Первичный ключ в таблице является базовым уникальным идентификатором для записей. Значение первичного ключа используется везде, где нужно указать на конкретную запись. На использовании первичных ключей основана организация связей между таблицами реляционной БД. Чтобы организовать между двумя таблицами связь типа «один к одному» или «один ко многим(многие к одному)» в одну из связываемых таблиц добавляют поле (поля), содержащее(ие) значение первичного ключа записи в связанной таблице (такое поле называют внешним ключом). Для организации связи типа «многие ко многим» создают отдельную таблицу (так называемую «таблицу связи» или «таблицу ассоциации»), каждая запись которой содержит первичные ключи двух связанных записей в разных таблицах. Классификация Простые и составные ключи Первичный ключ может состоять из единственного поля таблицы, значения которого уникальны для каждой записи. Так, например, на предприятии не может быть двух работников с одинаковыми табельными номерами, поэтому в таблице, содержащей записи о работниках, табельный номер может быть первичным ключом. Такой первичный ключ называют простым ключом. Если таблица не имеет единственного уникального поля, первичный ключ может быть составлен из нескольких полей, совокупность значений которых гарантирует уникальность. Так, имя, фамилия, отчество, номер паспорта, серия паспорта не могут быть первичными ключами по отдельности, так как могут оказаться одинаковыми у двух и более людей. Но не бывает двух личных документов одного типа с одинаковыми серией и номером. Поэтому в таблице, содержащей записи о людях, первичным ключом может быть набор полей, состоящий из типа личного документа, его серии и номера. Такой первичный ключ называют составным ключом Все остальные ключи отношения называются возможными ключами. В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей. Рассмотренный иерархический и сетевой пример базы данных, содержащей сведения о подразделениях предприятия и работающих в них сотрудниках, применительно к реляционной модели будет иметь вид:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Последнее изменение этой страницы: 2020-02-16; Просмотров: 121; Нарушение авторского права страницы
(не обязательно различных) декартовым произведением 
называется множество произведений вида: 
, где 
