Лекции по Базам данных. лекции. Развитие технологий обработки данных
 Скачать 0.53 Mb.
|
|
Даталогическое проектирование. Каждая система управления базой данных работает с допустимыми для нее логическими единицами данных и при этом может использовать определенные правила композиции логических структур. Композиция логических структур более высокого уровня производится из составляющих информационных единиц более низкого уровня. Система управления базой данных может накладывать структурные ограничения количественного или иного характера. Поэтому сначала детально изучаются особенности системы управления базой данных, определяются факторы, влияющие на выбор проектного решения, ознакомляются с существующими методиками проектирования, анализируются имеющихся средств автоматизации проектирования, возможности и целесообразности их использования и только после этого приступают к построению даталогической модели. На даталогическое проектирование оказывает влияние система управления базой данных возможностью своей физической организации данных, несмотря на то, что даталогическое проектирование является проектированием логической структуры. Именно поэтому, полезным при проектирование логической структуры, является знание особенностей физической организации данных. Заполненная данными база данных и ее логическая структура являются воспроизведением реальной предметной области. Именно поэтому специфика отображаемой предметной области отраженная в инфологической модели оказывает влияние на выбор проектных решений. Описание логической структуры базы данных на языке описания данных (ЯОД) является результатом даталогического проектирования. Проект логической структуры базы данных формирует определение всех информационных единиц и их взаимосвязи, а также задание им имен. Если используются разные типы информационных единиц, тогда необходимо определение их типов. Задаются и некоторые количественные характеристики например длина поля. Свои специфические особенности имеет каждый тип модели данных и каждая разновидность модели, поддерживаемая конкретной системой управления базой данных. Надо также отметить, несмотря на индивидуальность, во всех структурированных моделях данных и принципах проектирования баз данных в различных средах имеется много общего. Это дает возможность использовать инфологическую модель как общий, единый методологический аппарат для подхода к проектированию структуры базы данных. Проектирование базы данных, как процесс, нуждается в предварительной классификации объектов предметной области и в систематизации представление информации об «межобъектных» связях и самих объектах. Состав базы данных определяется на начальных этапах проектирования. Проектирование логической структуры базы данных сопровождается преобразованием исходной инфологической модели в модель данных, для конкретной базы данных и проверкой адекватности полученной даталогической модели отображаемой предметной области. Существует множество вариантов проектных решений ее отображения в даталогической модели для любой предметной области. Методология проектирования должна обеспечить выбор наиболее подходящего проектного решения. Минимальная логическая единица данных для всех систем управления базами данных равнозначна и соответствует либо идентификатору объекта, либо его свойству (объекта или процесса). Рассмотрим связи между сущностями предметной области, которые отражены в инфологической модели и могут быть отображены в даталогической модели. Их отражение производится либо посредством совместного расположения соответствующих им информационных элементов, либо путем объявления связи между ними. Связь может быть передаваться как на «внутризаписном», так и на «межзаписном» уровнях. В конкретной даталогической модели могут быть отражены не все виды связей, существующие в предметной области. Многие из систем управления базой данных не поддерживают отношение между элементами типа M:M. И в этом случае для отображения этой связи в даталогическую модель вводится специальный дополнительный элемент. Логическая структура базы данных проектируется с упором на специфику отображения предметной области. На проектное решение оказывает влияние и характер обработки информации. Вот, например, часто можно встретить рекомендации, которые говорят о хранении вместе той информации, которая обрабатывается совместно и наоборот, не хранить вместе (разделять по разным файлам) информацию, не использующуюся совместно. Рекомендация еще может быть такая, которая говорит что часто используемую информацию, и мало используемую информацию тоже следует хранить в разных файлах. Если говорить о мало используемой информации ее может оказаться выгодным вообще вынести в архивные файлы, а не поддерживать в составе базы данных. Инфологическая модель включает в себя всю информацию о предметной области. Этой информации для проектирования базы данных необходимо и достаточно. Этот факт надо учитывать при переходе от инфологической модели к даталогической. Это не означает, что в даталогической модели должны быть отражены все сущности, имеющиеся в инфологической модели. Решение о том, какая информация будет храниться в базе данных, является первоочередным для построения даталогической модели. К примеру, вычислительные показатели должны быть отражены в инфологической модели, но совсем не обязательно они должны хранится в базе данных. Есть различные подходы к определению достаточного состава показателей, хранящихся в базе данных. Один из подходов говорит, что в базе данных должны храниться только исходные показатели, а все производные от исходных показателей должны быть получены расчетным путем в момент реализации запроса. Такой подход называется принципом синтезирования, который подразумевает возможность «синтезировать» требуемые показатели из хранимых в информационной базе данных. Рассмотрим достоинства данного подхода: принятие решения «что хранить» является простым и однозначным; неявное дублирование информации отсутствует, следовательно, затрачивается меньшие объемы памяти, чем при хранении как исходных, так и производных показателей, и значительно упрощаются проблемы, связанные с контролем целостности данных; возможность получить не только те показатели, которые хранятся в базе данных, но и любой расчетный показатель. Ключевым полем файла является идентификатор объекта, отражающего объект в файле базы данных. В некоторых случаях есть необходимость введения искусственных идентификаторов, которые называются кодами. Рассмотрим такие случаи: 1. Появление в предметной области синонимии, когда идентификатор не обладает уникальностью. Среди сотрудников организации могут быть однофамильцы. В этом случае однозначная идентификация обеспечивается использованием искусственных кодов. 2. Повторение идентификатора объекта вызвано многосвязным участием объекта и в этом случае создается несколько файлов. Чтобы не использовать во всех этих файлах длинного естественного идентификатора объекта вводится более короткий код. Кроме экономии памяти это позволит уменьшить трудоемкость ввода информации. 3. Изменение со временем естественного идентификатора приводит к различным проблемам. Исправить это можно использованием дополнительного «статического» искусственного идентификатора к уже используемому «динамическому». Когда идентификаторы присваиваются каким-либо объектам, то хорошо бы, чтобы они были постоянными. Выполнение шагов проектирования даталогической модели производится итеративно. Итерации внутри стадии даталогического проектирования не ограничиваются, а происходят с «захватом» других смежных стадий проектирования базы данных. Напомним, предметной областью будем называть конкретные явления реального мира, представляющие интерес для проводимого нами исследования. Проектирование или непосредственное моделирование базы данных представляет собой сложный многоэтапный процесс. Рассмотрим эти основные этапы. Они приведены на рисунке 5.2. Дадим краткое описание приведенных на рисунке блоков. Особое внимание при рассмотрении блоков 1 и 2 следует обратить на понятие абстрагирования. Это связано с тем, что процесс проектирования базы данных ведется не под конкретный документ или действия пользователя с этим документов, а под абстрактный или обобщенный образ документа и такие же под абстрактные или обобщенные действия пользователей. Например рассматривается документ с абстрактными числами n и m, а не с конкретными числами строк и столбцов, или рассматривается поиск по любому полю, вместо требуемого для пользователя поиска по определенному полю. Важность состоит в том, что часто меняется форма документов и действия пользователя при работе с ними. Процесс проектирования может осложниться дополнительными временными или стоимостными затратами, если каждый раз при изменении вышеприведенных форм придется заниматься перепроектированием. В блоке 4 производится выбор системы управления базой данных. От этого выбора зависит в значительной степени работоспособность созданной базы данных. На выбор системы управления базой данных влияет количество форм используемых пользователем документов, сложность связей, объем информации обрабатываемой в базе данных, количество работающих с базой данных пользователей и многое другое. Системой управления базой данных производится отображение логической модели в структуру хранения, то есть представление информации в памяти компьютера. Для повышения эффективности функционирования многими системами управления базами данных осуществляется представление выбора параметров, которые могут затем оказывать влияние на представление данных в памяти компьютера. В 6 блоке осуществляется выбор таких параметров.  Рисунок 5.2 – Этапы проектирования базы данных Оценка возможной работоспособности базы данных является очень важной составляющей в процессе проектирования БД. Процесс проектирования завершается оценкой при реализации предполагаемых запросов пользователей. Если в рамках построенной модели нет возможности отвечать на предполагаемые запросы, то необходимо произвести возврат на шаг назад и построить более эффективное обобщенное концептуальное представление, которое уже не приведет к невозможности реализации соответствующего запроса в реальном масштабе времени. Такие оценки производятся и при завершении других этапов проектирования в блоках 6 и 7. При этом в процессе проектирования базы данных всегда предполагается возврат на один или несколько шагов назад. Это производится и в случае если при проектировании логической модели в блоке 5 не удалось достичь адекватного представления концептуальной модели средствами системы управления базой данных. В этом случае либо надо возвратиться на шаг назад, либо произвести выбор другой системы управления базой данных, либо изменить вид концептуальной модели, вернувшись к блоку 3. Если при завершении процесса проектирования, произведя оценки эксплуатационных характеристик в блоке 7, мы видим что они не отвечают требованиям пользователя, возможен пересмотр всех уже принятых решений в блоках 3, 4, 5, 6, 7. И в дополнение производится возврат к проектированию обобщенного концептуального представления в тех случаях, когда меняются внешние требования пользователей и при выявлении явных ошибок в проектировании. Описание предметной области. ЕR-диаграмма Покажем вводимые понятия на этапе проектирования базы данных в доступной для студента и близкой для восприятия форма. Рассмотри предметную область на примере студентов вуза. Необходимо дать краткое описание предметной области. В некотором вузе имеется несколько факультетов. На каждом факультете ведется подготовка студентов по нескольким специальностям и направлениям подготовки. Для каждого направления или специальности на факультете выработан свой конкретный учебный план. В этом плане приводится перечень изучаемых курсов по учебной программе с приведением количества учебных часов по разным видам занятий. Студенты, которые учатся на конкретном направлении факультета, изучают представленные в учебной программе дисциплины и сдают различные курсовые и промежуточные контроли, при этом получают зачеты и оценки. В этом случае концептуальная модель может быть представлена в виде диаграммы сущностей – связей (entity – relationship) или ЕR-диаграммы. Процесс непосредственного построения диаграммы «сущностей – связей» называется ЕR-моделированием. С помощью каких понятий можно описать предметную область? Дадим краткое описание таких основных понятий. Сущностью (Еntity) или объектом информационной системы называется нечто такое, за чем хотелось бы наблюдать пользователю (о чем будет собираться информация). Если в информационной системе обрабатывается информация о факультетах, сущностью будет считаться факультет, если в информационной системе обрабатывается информация о студентах, сущностью будет считаться студент и так далее. Сущности при моделировании «сущность – связь» имеет имя, которое обычно записывается заглавными буквами. Каждой сущности присущи определенные свойства, набор которых зависит от интереса пользователя и рамок проводимых исследований. Эти свойства запоминаются в информационной системе. Поясним, в качестве свойства сущности ФАКУЛЬТЕТ может быть указан номер этого факультета или его название. В качестве свойства сущности СТУДЕНТ может быть указана фамилия, дата рождения, место рождения или номер зачетной книжки. В качестве свойства сущности ЭКЗАМЕН может быть указан предмет, дата проведения экзамена и экзаменатор (или несколько экзаменаторов). Введение атрибута осуществляется для информационного описания сущности. Атрибут называется поименованное свойство или характеристика сущности. Атрибут представлен информационным отображением свойства сущности и принимает некоторое конкретное значение из множества допустимых значений. Приведем пример. Для сущности ФАКУЛЬТЕТ атрибутом будет «название». И соответственно конкретный экземпляр сущности принимает конкретное значение, то есть название – «экономический факультет». Атрибут не только представляет информационное описание количественных или качественных свойств сущности. Он так же описывает состояние сущности и позволяет ее идентифицировать. Совокупностью атрибутов представлена наиболее полная информация о сущности. Такая совокупность атрибутов обычно называется записью об объекте. Есть так же понятие класса сущностей. Классом сущностей или наборов объектов называется совокупность сущностей, характеризующихся в информационной системе одинаковыми наборами свойств. Поясним. Совокупность всех сущностей СТУДЕНТ составляет класс сущностей СТУДЕНТ, совокупность всех сущностей ФАКУЛЬТЕТ составляет класс сущностей ФАКУЛЬТЕТ. Класс сущностей описывается перечнем свойств сущностей, составляющих этот класс. Сущность с конкретными значениями соответствующих свойств является конкретная сущность и называется экземпляром сущности. Ранее было определено предназначение сущности как накопителя информации в информационной системе. Но это только одно направление для чего предназначена сущность. Данные должны не просто накапливаться и храниться. Они должны использоваться для потребителя с точки зрения удовлетворения информационных потребностей. Интересующий пользователя экземпляр сущности может, в последствии, обрабатываться, корректироваться или удаляться. Нахождение экземпляра сущности производится для реализации запросов. Однозначная идентификация является важнейшим свойством сущности. Она производится по уникальному идентификатору в виде одного или группы атрибутов. Для сущности ФАКУЛЬТЕТ уникальным атрибутом будет номер или название. Для сущности СТУДЕНТ уникальным атрибутом будет фамилия, имя отчество или специальный идентификатор присваиваемый студентам при зачислении, так называемый «код студента». ЕR-диаграмма является самым распространенным способом для представления концептуальной модели. ЕR-диаграмма может обозначаться по разному в зависимости от источников, стандартов или программных продуктов. Ознакомившись с документацией можно в кратчайшие сроки освоить используемую систему обозначений. Практически разность в обозначениях не вызывает у проектировщиков сложностей. Представим один из вариантов. Представим ЕR-диаграмму где класс сущностей будет представлен в виде четырехугольника. В этом четырехугольнике будет записано прописными буквами уникальное имя класса сущности и строчными буквами имена атрибутов данной сущности. Пример класса сущности СТУДЕНТ представлен на рисунке (Рис. 5.3).  Рисунок 5.3 – Класс сущностей и экземпляр сущности Нахождение интересующей пользователя экземпляр сущности является не достаточным условием для реализации его информационных потребностей. Функциональные взаимоотношения тесно связаны с информационными потребностями. Необходимость определения, на каком факультете учится студент, связывает функциональными взаимоотношениями, существующими в организации с информационными потребностями. Такие запросы, как информационные потребности пользователя реализуются с использованием взаимоотношений между сущностями, которые существуют в предметной области. Эти взаимоотношения определяются связями (Rеlаtionships). Можно выделить экземпляры связей и классы связей. Различают классы связей и экземпляры связей. Экземпляры связей это взаимоотношения между экземплярами сущностей. Классы связей это взаимоотношения между классами сущностей. Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи n = 2, 3, ... Связь «учится на факультете» связывает класс сущностей ФАКУЛЬТЕТ с классом сущностей СТУДЕНТ. Степень этой связи равна двум. При n =2 связь называется бинарной. Связь в этом случае рассматривается как двусторонняя: «на факультете учатся студенты» и «студент учится на факультете». Классифицируем бинарные связи. По критерию зависимости связи экземпляров сущности различных классов, классифицировать можно по типам: Связь 1:1 (один на один). Одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса. Например, связь между классами сущностей ФАКУЛЬТЕТ и УЧЕБНЫЙ ПЛАН ДИСЦИПЛИНЫ ПО НАПАРАВЛЕНИЮ ДЛЯ ФАКУЛЬТЕТА (каждому факультету соответствует свой учебный план по определенному направлению или по специальности). Связь 1:М (один ко многим). Единый экземпляр сущности одного класса связан со многими экземплярами сущности другого класса. Например, связь между классами сущностей ФАКУЛЬТЕТ и СТУДЕНТ (на одном факультете может учиться большое количество студентов). Связь М:N (многие ко многим). Несколько экземпляров сущности одного класса связаны с несколькими экземплярами сущности другого класса. Например, связь между классами сущностей ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ (на факультете может быть несколько направлений или специальностей и одно и то же направление или специальность может быть на нескольких факультетах). Максимальное количество сущностей на каждой стороне связи описывается числами, которые обозначены типами бинарных связей (1:1, 1:М, М:N). Эти числа, которые описывают максимальное количество сущностей, называются максимальными кардинальными числами, а соответствующая пара чисел называется максимальной кардинальностью. Имеется возможность договорится по состоянию диаграммы «сущность – связь». Приведем пример. Связь между сущностями обозначим стрелкой и рядом указывается имя связи и тип связи. Рассмотрим диаграмму «сущность – связь» с сущностями СПЕЦИАЛЬНОСТЬ, СТУДЕНТ, ФАКУЛЬТЕТ представленную на рисунке 5.4. Уникальный идентификатор должен иметь каждый экземпляр сущности, то есть каждый экземпляр сущности должен уникально идентифицироваться. Это связано с тем, что возникает неоднозначность. Могут быть несколько студентов с одинаковой фамилией и в этом случае необходимо вводить дополнительный атрибут «студенческий код». К сущности ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ дополнительным атрибутом будет номер или название, которое уже будет уникальным идентификатором.  Рисунок 5.4 – Пример фрагмента диаграммы «сущность – связь» Рассмотрим действие по диаграмме «сущность – связь» (ЕR-диаграмме). При реализации запроса пользователя может быть указана последовательность действий. При реализации запроса «на каком факультете учится студент Кузнецов» выполняются следующие действия: среди экземпляров сущности СТУДЕНТ экземпляр с фамилией Кузнецов, затем переходится по связи «студент учится на факультете» к экземпляру сущности ФАКУЛЬТЕТ, производится чтение значения атрибута «Название», которое соответствует искомому названию факультета. Иногда на диаграмме «сущность – связь» две связи могут отображаться одной двухсторонней стрелкой или просто линией. На приведенной диаграмме «сущность – связь» на логическом и на физическом уровнях не представлены какие-либо способы реализации этих связей. Эти способы реализующие связи зависят от возможностей модели данных конкретной системы управления базой данных. Они рассматриваются на второй стадии концептуального проектирования при представлении концептуальной модели средствами модели данных системы управления базой данных. Построение концептуальной модели в виде ER-диаграммы |