Главная страница
Культура
Искусство
Языки
Языкознание
Вычислительная техника
Информатика
Финансы
Экономика
Биология
Сельское хозяйство
Психология
Ветеринария
Медицина
Юриспруденция
Право
Физика
История
Экология
Промышленность
Энергетика
Этика
Связь
Автоматика
Математика
Электротехника
Философия
Религия
Логика
Химия
Социология
Политология
Геология

Лекции по СУБД. Субд. Маршалов Е. Д. Зачет тк1 посещаемость. Список литературы



Скачать 9.79 Mb.
Название Субд. Маршалов Е. Д. Зачет тк1 посещаемость. Список литературы
Анкор Лекции по СУБД.docx
Дата 01.05.2017
Размер 9.79 Mb.
Формат файла docx
Имя файла Лекции по СУБД.docx
Тип Документы
#5395

12.02.14

СУБД. Маршалов Е.Д. / Зачет / ТК1 - посещаемость.

Список литературы:

  1. Кренке Давид М. Теория и практика построения БД. - 2005 г. - 859 стр.

  2. Дейд Крис Джей. Введение в систему БД. - 2001 г. - 1072 стр.

  3. Ратманова И.Д. Проектирование БД и разработка приложений в СУБД. Microsoft SQL Server. - 2010 г. - 116 стр.

Тема 1.

Основные сведения о БД и СУБД.

Понятие БД.

Информация - любые сведения о каком-либо событии, сущности, процессе и т.п.

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

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

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

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

  2. Обеспечивать заданный уровень достоверности информации и ее непротиворечивость.

  3. Обеспечивать доступ к данным только пользователей с соответствующими полномочиями.

  4. Обеспечить возможность поиска информации по произвольной группе признаков.

  5. Удовлетворять заданным требованиям производительности при обработке запросов.

  6. Иметь возможность реорганизации и расширения при расширении границ предметной области.

  7. Обеспечивать выдачу информации пользователем в различной форме.

  8. Обеспечивать простоту и удобство обращения пользователей за информацией.

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

Соответственно двум понятиям "информация"и "данные"в БД различают 2 аспекта рассмотрения вопросов:

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

  2. Даталогический - Употребляется при рассмотрении вопросов представления данных в памяти системы.

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

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

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

Современная СУБД реализует централизованное управление данными и кроме того обеспечивают:

  1. Определение данных, подлежащих хранению в БД.

  2. Первоначальную загрузку данных в БД, т.е. создание БД.

  3. Обновление данных.

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

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

1.2.1. Обобщенная архитектура СУБД.

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

  1. Физическом размещении в памяти данных и их описании.

  2. Механизмов поиска запрашиваемых данных.

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

  4. Способов обеспечения защиты данных от некорректных обновлений и несанкционированного доступа.

  5. Поддержание БД в актуальном состоянии и множестве других функций СУБД.

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

  1. Сущности, интересующие предметные области.

  2. Атрибуты, характеризующие неотъемлемое свойства каждой сущности.

  3. Связи, ассоциирующие выделенные сущности.

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

Трехуровневая архитектура ANSI/SPARC.



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

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

  2. Пользователи не должны иметь дело с деталями физической организации данных.

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

  4. Структура БД не должна зависеть от физических аспектов хранения.

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

17.02.14

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

  1. Сущности, их атрибуты и связи.

  2. Ограничения накладываемые на данные.

  3. Семантическую информацию о данных.

  4. Информацию о мерах обеспечения информации.

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

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

Соответствующие 3-х уровневой архитектуре (системе) ANCI/SPARC 3 уровня модели данных для описания предметной области и реализации БД представлена следующим рисунком:

Уровни моделей данных



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

Основные компоненты типичной СУБД





Достоинства и недостатки СУБД.

Достоинства:

  1. Контроль за избыточностью данных.

  2. Не противоречивость данных

  3. Больший объем полезной информации, при том же объеме хранимых данных

  4. Совместное использование данных.

  5. Поддержка целостности данных.

  6. Повышенная безопасность.

  7. Применение стандартов.

  8. Повышение эффективности с ростом масштабов системы.

  9. Возможность нахождения компромисса при противоречивых требованиях.

  10. Повышение доступности данных.

  11. Улучшение показателей производительности.

  12. Упрощение сопровождения системы за счет независимости данных.

  13. Улучшенное управление параллельностью.

  14. Развитые службы резервного копирования и восстановления.

Недостатки СУБД:

  1. Сложность.

  2. Стоимость

  3. Дополнительные затраты на аппаратное обеспечение.

  4. Затраты на преобразование.

  5. Серьезные последствия при выходе системы из строя.

Категории пользователей БД.



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

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

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

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

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

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

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

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

Проектирование БД.

Жизненный цикл информационной системы.

БД является фундаментальным компонентом информационной системы, поэтому жизненный цикл информационной системы неотъемлемо связан с жизненным циклом лежащий в основе БД и состоит из следующих основных этапов:

лежащий в основе БД и состоит из следующих основных этапов:

  1. Планирование.

  2. Сбор и анализ требований к системе.

  3. Проектирование системы.

  4. Создание прототипа.

  5. Реализация.

  6. Тестирование.

  7. Преобразование.

  8. Сопровождение.


18.02.14

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

Жизненный цикл информационной системы на основе базы данных.



2.2. Подходы и этапы проектирования БД.

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

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

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

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

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

Этапы проектирования БД.

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

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

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

  1. Телеобработка.

  2. Файловый сервер.

  3. Технология "клиент/сервер".

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

Архитектура с использованием файлового сервера.



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

Общая схема построения систем с архитектурой "клиент/сервер".



Недостатки данной архитектуры:

  1. Большой объем сетевого трафика.

  2. На каждой рабочей станции должна находится полная копия СУБД.

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

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

Пример ER-диграммы.



Операции выполняемые клиентом:

  1. Управляет пользовательским интерфейсом.

  2. Принимает и проверяет синтаксис, введенного пользователем, запроса.

  3. Выполняет приложение.

  4. Генерирует запрос к БД и передает его серверу.

  5. Отображает полученные данные пользователю.

Функции, выполняемые сервером:

  1. Принимает и обрабатывает запросы к БД со стороны клиента.

  2. Проверяет полномочия пользователей.

  3. Гарантирует соблюдение ограничений целостности.

  4. Выполняет запросы и обновления, а так же возвращает результаты клиенту.

  5. Поддерживает системный потолок.

  6. Обеспечивает параллельный доступ к БД.

  7. Обеспечивает управление восстановлением.

Основные преимущества:

  1. Повышается общая производительность системы.

  2. Снижается стоимость аппаратного обеспечения.

  3. Сокращаются коммуникационные расходы.

  4. Повышает уровень непротиворечивости данных.

3. Инфологическое проектирование БД.

3.1. Модель "сущность-связь".

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

  1. Семантические сети.

  2. Язык инфологического моделирования.

  3. ER-диаграммы.

Наибольшую популярность из-за доступности, наглядности и компактности приобрел подход моделирования "сущность-связь". Модель "сущность-связь" разработана с целью упрощения концептуального проектирования БД. Основными элементами это модели являются:

  1. Сущности.

  2. Атрибуты.

  3. Связи.

Сущность представляет собой различимое множество объектов (экземпляров сущности) реального мира с одинаковым набором свойств или атрибутов. Сущность идентифицируется именем и списком свойств или атрибутов. Каждый экземпляр сущности обладает уникальным набором значения атрибутов. На ER-диаграммах сущность представляется прямоугольником с именем сущности внутри.

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

  1. Простые.

  2. Составные.

  3. Однозначные.

  4. Многозначные.

  5. Производные.

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

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



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

Связь ОДИН-К-ОДНОМУ.



При связи "один ко многим" каждому экземпляру сущности A соответствует 0, 1 или несколько представителей сущности B.

Связь ОДИН-КО-МНОГИМ.



При связи "многие ко многим" каждому экземпляру сущности A соответствует 0, 1 или несколько сущностей B, а каждому экземпляру сущности B соответствует 0, 1 или несколько сущностей A.

Связь МНОГИЕ-КО-МНОГИМ.



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

Пример связи БРАК между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ.



Характер связи между сущностями может оказаться более сложным.

Пример множества связей между сущностями ПРЕПОДАВАТЕЛЬ и СТУДЕНТ.



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

СУЩНОСТЬ (атрибут 1, атрибут 2, ... , атрибут n).

СВЯЗЬ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...] (атрибут 1, атрибут 2, ... , атрибут n)

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

ПРЕПОДАВАТЕЛЬ (УслНомерП, Фамилия, Имч, Отчество, УчСтепень)

СТУДЕНТ (УслНомерС,, Фамилия, Имя, Отчество, Адрес, Специальность, Пол)

Лектор [ПРЕПОДАВАТЕЛЬ 1, СТУДЕНТ M] (УслНомерП, УслНомерС)

Консультант [ПРЕПОДАВАТЕЛЬ N, СТУДЕНТ P] (УслНомерП, УслНомерС).

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

Проблемы ER моделирования.

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

  1. Ловушки разветвления.

  2. Ловушки разрыва.

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

Пример ловушки разветвления.



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

Семантическая сеть ER-модели с ловушкой разветвления.



С помощью семантической сетевой модели на конкретном примере невозможно дать однозначный ответ на вопрос по какой специальности обучается студент Гавриюхов. Это ловушка разветвления, произошедшая из-за неправильной трактовки связей между сущностями - ФАКУЛЬТЕТ, СПЕЦИАЛЬНОСТЬ, СТУДЕНТ. Устранить такой дефект можно только путем перестройки исходной модели.

Преобразованная ER-модель.



26.02.14

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

Семантическая сеть преобразованной ER-модели.



Ловушка разрыва.

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

Пример ловушки разрыва.



Семантическая сеть ER-модели с ловушкой разрыва.



Преобразованная ER-модель.



Семантическая сеть преобразованной ER-модели.



Даталогические модели данных.

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

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

  2. Допустимые операции, выполняемые на структуре данных.

  3. Ограничение для контроля целостности.

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

1. Иерархическая модель данных - это представление БД в виде древовидной иерархической структуры, состоящей из объектов различных уровней.

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

Иерархическая модель данных.



Из этого примера видны недостатки иерархических БД:

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

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

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

Сетевая модель данных.



3. Реляционная модель данных.

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

Реляционная модель данных.



Реляционная модель данных.



Внутренний язык СУБД.
написать администратору сайта