Оптимальная модель данных должна удовлетворять таким критериям, как структурная достоверность, простота, выразительность, отсутствие избыточности, расширяемость, целостность, способность к совместному использованию.
Параллельно с проектированием системы БД выполняется разработка приложений. Главные составляющие данного процесса – это проектирование транзакций и пользовательского интерфейса.
На данном этапе осуществляется физическая реализация базы данных и разработанных приложений, позволяющих пользователю формулировать требуемые запросы к БД и манипулировать данными в БД. На этом этапе реализуются также используемые приложением средства защиты базы данных и поддержки ее целостности. Реализация этого, а также и более ранних этапов проектирования БД может осуществляться с помощью инструментов автоматизированного проектирования и создания программ, которые принято называть CASE-инструментами. Использование CASE-инструментов способствует повышению производительности труда разработчиков и обеспечению эффективности самой разрабатываемой системы.
На этом этапе созданные в соответствии со схемой базы данных пустые файлы, предназначенные для хранения информации, должны быть заполнены данными. Наполнение базы данных может протекать по-разному, в зависимости от того, создается ли база данных вновь или новая база данных предназначена для замены старой.
В первом случае для ввода информации используются созданные в процессе проектирования БД удобные специальные формы, которые позволят администратору базы данных занести в базу заранее подготовленные данные.
Если же новая база данных предназначена для замены старой, то возникает проблема переноса данных в новую систему, причем очень часто с преобразованием формата их представления. Данная задача получила название – конвертирование данных. В настоящее время любая система управления базами данных имеет утилиту загрузки уже существующих файлов в новую базу данных.
Тщательное тестирование должен проходить любой программный продукт тем более такой, как прикладные программы информационной системы. Стратегия тестирования должна предполагать использование реальных данных и должна быть построена таким образом, чтобы весь процесс выполнялся строго последовательно и методически правильно. Помимо обнаружения имеющихся в прикладных программах и, возможно, в структурах базы данных ошибок, сбор статистических данных на стадии тестирования позволяет установить показатели надежности и качества созданного программного обеспечения.
Данный этап является последним, но, безусловно, и самым продолжительным в жизненном цикле правильно спроектированной базы данных. Основные действия, связанные с этим заключительным этапом, сводятся к наблюдению за созданной системой, поддержке ее нормального функционирования, а также к созданию дополнительных программных компонент или модернизации самой базы данных.
С ростом популярности СУБД в 70-80-х годах появилось множество различных моделей данных. У каждой из них имелись свои достоинства и недостатки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить первые модели данных.
Модель данных (МД) – это некоторая абстракция, в которой отражаются самые важные аспекты функционирования выделенной предметной области, а второстепенные – игнорируются. Модель данных включает в себя набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные.
Существуют три основные МД и их комбинации, на которых основываются современные БД: реляционная модель данных (РМД), сетевая модель данных (СМД), иерархическая модель данных (ИМД).[3]
Основное различие между этими моделями данных состоит в способах описания взаимодействий между объектами и атрибутами. Взаимосвязь выражает отношение между множествами данных.
Используют взаимосвязи "один к одному", "один ко многим" и "многие ко многим". "Один к одному" – это взаимно однозначное соответствие, которое устанавливается между одним объектом и одним атрибутом. "Один ко многим" – это соответствие между одним объектом и многими атрибутами. "Многие ко многим" – это соответствие между многими объектами и многими атрибутами.
Рассмотрим эти модели данных более подробно.
Основными информационными единицами в иерархической модели данных являются сегмент и поле. Поле данных определяется как наименьшая неделимая единица данных, доступная пользователю. Для сегмента определяются тип сегмента и экземпляр сегмента. Экземпляр сегмента образуется из конкретных значений полей данных. Тип сегмента – это поименованная совокупность входящих в него типов полей данных.
Иерархическая модель данных базируется на графовой форме построения данных. В ИМД вершине графа соответствует сегмент, а дугам – типы связей предок-потомок. В иерархических структурах сегмент-потомок должен иметь в точности одного предка.
Сетевая модель опирается на математическую структуру, которая называется направленным графом. Направленный граф состоит из узлов, соединенных ребрами. В контексте моделей данных узлы представляют собой объекты в виде типов записей данных, а ребра – связи между объектами со степенью кардинальности "один к одному" или "один ко многим".
Основное отличие графовых форм представления данных в сетевой структуре данных от иерархической структуры данных состоит в том, что потомок в графе может иметь любое число предков.
Недостатки иерархической и сетевой моделей привели к появлению новой, реляционной модели данных, созданной Коддом в 1970 году и вызвавшей всеобщий интерес. Реляционная модель была попыткой упростить структуру базы данных. В ней отсутствовали явные указатели на предков и потомков, а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы.
Именно реляционная модель является результатом более развитых представлений о формировании и ведении баз данных, на которые наложен строгий математический аппарат. Реляционные модели наиболее логично и наглядно отражают структуру хранимой информации и внутренних связей, что позволяет более полно анализировать структуру базы данных при разработке. Это привело к тому, что именно реляционные модели баз данных наиболее распространены в настоящее время и являются стандартом, на который переводятся все существовавшие ранее базы данных с иерархической и сетевой моделью. Ещё одним веским доводом в пользу выбора реляционной модели является тот факт, что подавляющее большинство предоставляемых средств для разработки баз данных ориентированы исключительно на реляционную модель. Кроме того, реляционные базы данных в последствии легче расширять и интегрировать, что является неотъемлемой частью дальнейшего развития баз данных, с увеличением возлагаемых на них задач.
Реляционной называется база данных, в которой все данные, доступные пользователю, организованны в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами.[7]
Приведенное определение не оставляет места встроенным указателям, имеющимся в иерархических и сетевых СУБД. Несмотря на это, реляционная СУБД также способна реализовать отношения предок/потомок, однако эти отношения представлены исключительно значениями данных, содержащихся в таблицах.
Достоинства реляционной модели можно разделить на две группы.
Достоинства для пользователя:
реляционная БД представляет собой набор таблиц, с которыми пользователь привык работать;
не нужно помнить пути доступа к данным и строить алгоритмы и процедуры обработки своего запроса;
реляционные языки легки для изучения и освоения, в то время как языки общения с иерархической и сетевой моделями предназначены для программистов и мало пригодны для пользователей;
Достоинства обработки данных реляционной БД:
Связность. Реляционное представление дает ясную картину взаимосвязей атрибутов из различных отношений;
Точность. Направленные связи в реляционной БД отсутствуют. Отношения по своей природе обладают более точным смыслом и поддаются манипулированию с использованием таких средств, как алгебра и исчисление отношений, обеспечивающих наглядность и гибкость модели данных;
Гибкость. Операции проекции и объединения позволяют разрезать и склеивать отношения, так что программист может получать разнообразные файлы в нужной форме;
Секретность. Контроль секретности упрощается. Для каждого отношения имеется возможность задания правомерности доступа, засекреченные показатели можно выделить в отдельные отношения с проверкой прав доступа;
Простота внедрения. Физическое размещение однородных (табличных) файлов намного проще, чем размещение иерархических и сетевых структур;
Независимость данных. БД должна допускать возможность расширения, т.е. добавления новых атрибутов и отношений.[7]
Поскольку среди рассмотренных логических моделей данных реляционная обладает значительными преимуществами и малыми недостатками, то она и будет взята в основу для построения СУБД. Рассмотрим ее более подробно.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29
